[Gllug] ADVERT: Shell Scripting book

Nix nix at esperi.org.uk
Wed Jul 20 21:25:39 UTC 2011

On 20 Jul 2011, Steve Parker uttered the following:

> On 20/07/11 21:50, Alain Williams wrote:
>> 	foo=bar
>> 	echo $foo
>> 	env|grep foo
>> 	export foo
>> 	env|grep foo
> Here $foo has not been exported to env, but $foo is still a variable
> in your current running shell.

yes. This is called 'a shell variable.' It is not in the environment.

>       When a simple command other than a builtin or shell function is to be executed, it is invoked
>        in  a *separate execution environment* that consists of the following.  Unless otherwise noted,
>        the values are inherited from the shell.
>        *     the shell's open files, plus any modifications and additions specified by redirections
>               to the command
>        *      the current working directory
>        *     the file creation mode mask
>        *      shell variables and functions *marked for export*, along with variables exported for the
>               command, passed in the environment

The 'execution environment' of a shell is *not* the same thing as 'the
environment', which is a Unix convention with libc support available to
all programs, shell or not, and into which exported shell variables are
placed. POSIX.1 makes this distinction quite clear: search for
'environment' in
and observe the careful distinction drawn between 'the environment'
(without qualifiers) and 'the shell's execution environment': indeed
that distinction is essential if you are to understand POSIX's
description of the 'export' builtin.

True, the names are needlessly similar and confusing, but they are
distinct and quite different concepts.

> The shell's environment (realistically in this context, a shell
> script's environment) contains all of its variables (including an
> unexported $foo). External commands are run in their own environment;
> not all of your environment is exported to commands that you call, but
> all of your variables are part of your environment.

POSIX disagrees with your terminology quite violently, as does
historical Unix usage.

NULL && (void)
Gllug mailing list  -  Gllug at gllug.org.uk

More information about the GLLUG mailing list