Talk:Bourne Shell Scripting/Environment

Ugh!

Speaking as someone who's had to teach shell scripting I have to say that there are quite a few parts of text which I think will lead to considerable confusion.


 * The environment conflated with process state. A process' file descriptor list and signal handlers, etc, are not considered parts of the "environment." I think it's best to think of the environment specifically as the block of memory in which environment variables are stored
 * The positional arguments (represented as $1, etc.) are on the command line ... which is usually not thought of as part of the environment.
 * The environment is best described as a region of a process' memory which contains a list of name/value settings ... ASCII strings. It's used by the shell and by many of  the programs run under a shell as a way to store settings which can be specific to a process or to a family of processes.  (In other words its a way for configuration settings to be passed from a parent process to its descendents).
 * I find that it helps students understand the environment when I draw a conceptual memory map of a process ... explain the concepts of fork and execve ... and show how the execve replaces ... over-writes all of a process' memory except for the environment. This leads almost all students to an understanding of why the export command is used to shift variables and their values out of the local heap and into the environment and gives them the insight to understand why environment variables can only be "inherited" and why the cannot be modified by subshells and other sub-processes.
 * Explaining a little about the underlying, fundamental, fork/exec* model also helps the student understand the most basic command executions on a much deeper level. They learn that all normal external command execution involves a subshell which exec*s a program while their shell wait*s for it to complete.
 * As we get into more advanced topics it becomes far easier for them to master concepts such as pipes (which are, after all, an inter-process communications mechanism --- and thus inherently involve a subshell or other subprocess), the exec shell command (when used for purposes other than file descriptor manipulation), and from there the concepts in eval and source (the . command).

In other words I think that peeling away a little of abstraction layering ... and giving the students a peek at the inner workings of these things builds a solid foundation on which they can progress more confidently.

(So I need to re-write this section a bit ... but first I wanted to post it here to the discussion to here any dissenting opinions). JimD 07:53, 2 April 2007 (UTC)