Category:UNIX Shell Implementations: Difference between revisions

There are many [[UNIX Shell|UNIX Shells]]s and most of them canbelong be categorized intoto two families. For purposes of the Rosette Code, all examples are in Bourne-compatible syntax. The other family of shells, with a markedly different syntax, are ''csh'' and it'sits ''tcsh'' (Tenex C Shell) "clone." Common Bourne compatible shells include the original [[Bourne Shell]] (''/bin/sh'' on most versions of UNIX), the GNU [[Bourne Again SHell]] (''bash'' --- which is linked to ''/bin/sh'' on many distributions of [[Linux]], making it their default shell), the [[Korn Shell]] (''ksh''), the [[Public Domain Korn SHell]] (''pdksh''), the [[Almquist SHell]] (''ash'') and the [[Debian Almquist SHell]] (''dash'') and the [[Z SHell]] (''zsh'').

... though this is technically a bug in the language parsing (The braces used for command grouping are not delimiters in the same class as semicolons nor parentheses; so this example is ambiguous because ''echo }'' (outside of any command grouping) should work the same as ''echo "}"'' --- but in bash versions 1.x it behaves inconsistently). In ''bash'' versions newer than 2.0 this was fixed and the following is required:

Variations of this bug probably accountsaccount for more "breakage" during upgrades of ''bash'' and when attempting to run ''bash'' scripts under other Bourne compatible shells than any other change in the history of Bourne-compatible shells.

Another common portability issue among different Bourne-compatible shells is a subtle matter of how pipe operations are handled. In all normal UNIX shells the '''''|''''' (pipe) operator creates a unidirectional inter-process communications (IPC) stream between one shell process and another. Thus a command like:

echo foo | read bar

... implicitly invokes a subshell (separate process) as either the producer or the consumer (writer into or reader from) this data "pipe."

The crucial differentdifference in semantics is determined by whether a given implementation of a shell creates the subshell/sub-process to the left or the right of the pipe operator. (Conceivably a shell could even create subprocesses on both sides of the operator). To demonstrate, and even test for, the difference run the following lines of code:

... shells such as ''ksh'' and ''zsh'' spawn their subshells to the left of the pipe ... so the sub-process is writing into the pipeline. This means that the existing process is reading values; thus the local shell variable "bar" is set after the second semicolon in this example. Under shells such as ''bash,'' ''ash,'' ''pdksh'' (and even in older versions of ''ksh'') the subshell is spawned on the right of the ''|'' operator. In those cases the ''read'' command is setting a value to a shell variable which ceases to exist after the second semicolon (which marks the end of that command, and thus the end of the completed sub-process.

Note that in all these examples the ''unset bar'' command is simply to avoid any confusion in the unlikely event that a variable named "bar" was present in the shell environment or local variable heap prior to our functional examples. This sort of difference, the implicit creation and scope of subshells and subproceses, and the underlying conceptual distinctions between shell and environment variables are at the root of many shell scripting portability issues and cause most of the confusion experienced by novices to UNIX shell scripting.

[http://athenawww.vvsumath.ruiitb.ac.in/resources/docsmanuals/unixUnix_Unleashed/unix_admVol_1/ch13.htm, anAn excerpt] from "UNIX Unleashed, System Administrator's Edition", has a decent discussion of how to choose a shell. The article focuses on three areas: command line usage, shell scripting for personal use and shell scripting for others to use.