Mail Archives: cygwin/2005/08/31/10:53:42
> Out of interest, is it correct behaviour for Bash to
> return a value for
> SHELL even though it hasn't been explicitly set?
See `man bash', under Shell Variables. Bash documents that if
SHELL is not set in the environment, then bash populates it as an
unexported variable with the full pathname of the current user's
login shell (sure enough, editing /etc/passwd affects what SHELL
contains).
> Presumably this is
> handled by Bash itself in such a way that getenv
> doesn't see it; is that
> in itself a bug?
No - there are two namespaces in a POSIX shell - shell variables,
and environment variables. By default, assigning to something
that is unset only makes it a shell variable, export is what you then
use to move that variable into the environment space. The only way
in POSIX to remove something from environment space is to unset
it, but bash also has export -n to keep the current value while pulling
it out of the environment. All variables are seen by subshells,
but only environment variables are seen by child processes. The
syntax "export foo=bar" is shorthand for "foo=bar; export foo",
both creating the variable and putting it in the environment;
POSIX requires this syntax, but older shells did not support it.
Since SHELL already exists as a shell variable, a simple
export SHELL
in your ~/.bash_profile will add it to the environment, without
changing its value from what it inherited as bash started,
or from what bash populated it with from /etc/passwd.
--
Eric Blake
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -