Classic Shell Scripting - Arnold Robbins [217]
DEBUG: This is /home/zabriski/.zshrc
DEBUG: This is /etc/zlogin
DEBUG: This is /home/zabriski/.zlogin
$ exit
Terminate the session
DEBUG: This is /home/zabriski/.zlogout
DEBUG: This is /etc/zlogout
An interactive session invokes fewer files:
$ zsh
Start a new interactive session
DEBUG: This is /etc/zshenv
DEBUG: This is /home/zabriski/.zshenv
DEBUG: This is /etc/zshrc
DEBUG: This is /home/zabriski/.zshrc
$ exit
Terminate the session
Silence: no termination files are read
A noninteractive session uses only two files:
$ echo pwd | zsh
Run a command under zsh
DEBUG: This is /etc/zshenv
DEBUG: This is /home/zabriski/.zshenv
/home/zabriski
* * *
[5] On many systems, /bin/sh is just a link to bash, in which case command history is available. However, the original Unix Bourne shell lacks command history.
Summary
The POSIX standard makes a yeoman effort to make portable shell scripting possible. And if you stay within the bounds of what it defines, you have a fighting chance at writing portable scripts. However, the real world remains a messy place. While bash and ksh93 provide a number of extensions above and beyond POSIX, things aren't always 100 percent compatible between the two shells. There are a large number of small Section 14.1 to watch out for, even in simple areas like set options or saving the shell's complete state.
The shopt command lets you control bash's behavior. We particularly recommend enabling the extglob option for interactive use.
bash and ksh93 share a number of common extensions that are very useful for shell programming: the select loop, the [[...]] extended test facility, extended pattern matching, brace expansion, process substitution, and indexed arrays. We also described a number of small but useful miscellaneous extensions. The arithmetic for loop and the ((...)) arithmetic command are perhaps the most notable of these.
Source code for bash and ksh93 is available for download from the Internet, and we showed how to build both shells. We also mentioned two other popular extended Bourne-style shells, pdksh and zsh.
We showed how to determine the version of the shell you're running for the popular extended Bourne-style shells. This is important for when you need to know exactly what program you're using.
Finally, different implementations of the Bourne shell language have different startup and termination customization features and files. Shell scripts intended for general use should not rely on features or variables being set by each individual user, but should instead do all required initialization on their own.
Chapter 15. Secure Shell Scripts: Getting Started
Unix security is a problem of legendary notoriety. Just about every aspect of a Unix system has some security issue associated with it, and it's usually the system administrator's job to worry about this issue.
In this chapter, we first present a list of "tips" for writing shell scripts that have a better chance of avoiding security problems. Next we cover the restricted shell, which attempts to put a straitjacket around the user's environment. Then we present the idea of a "Trojan horse," and why such things should be avoided. Finally we discuss setuid shell scripts, including the Korn shell's privileged mode.
* * *
Tip
This is not a textbook on Unix system security. Be aware that this chapter merely touches the tip of the iceberg and that there are myriad other aspects to Unix system security besides how the shell is set up.
If you would like to learn more about Unix security, we recommend Practical UNIX & Internet Security (O'Reilly).
* * *
Tips for Secure Shell Scripts
Here are some tips for writing more-secure shell scripts, courtesy of Professor Eugene (Gene) Spafford, the director of Purdue University's Center for Education and Research in Information Assurance and Security:[1]
Don't put the current directory (dot) in PATH
Executable programs should come only from standard system directories. Having the current directory (dot) in PATH