On Thu, 23 Mar 2017 17:17:52 -0000, Larry Hynes said:
Environment variables are referred to with and without a preceding
$. e.g.: mhl(1) has $TERM and $TERMCAP, while mhbuild(1) has PARINIT.
$HOME, frequently used in the FILES section as part of a /pathname,
is - I venture - OK. But I think cases like $TERM and $TERMCAP
might be more correctly used without the $.
Actual convo once:
"You're more pendantic than usual"
"You mean pedantic"
"No, *pendant*ic - you're just hanging around waiting for a chance to be a
Strictly speaking, the names of the environment variables are (usually)
upper-case strings like TERM. However, it isn't reasonable for a shell
to run through getenv() for every single "word" it parses out, so some
semantic glue is used - $TERM. The shell only has to recognize "word
does/doesn't begin with $" and then do a search for that shell or
So $FOO is a shell variable, whose value may possibly be interpolated from
the environment variable FOO.
All this magic can cause subtle errors. Consider these assignments:
Some shells will auto-export certain recognized shell variable such as $TERM or
$PATH or $HOME and export the value as an environment variable to any sub
shells/processes. They *won't* auto-export variables they don't recognize as
"important". So if you launch a subshell, TERM may propogate, and MH_WOMBAT
not (unless an 'export MH_WOMBAT' happened).
To muddy the waters even more, some shells (bash for instance) will allow
the export of *functions* to a sub-shell. Yes, this is "Here there be large
and nasty dragons" territory....
Description: PGP signature
Nmh-workers mailing list