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 pedant." 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 environment variable. 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: TERM=xterm MH_WOMBAT="foobar" 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....
pgpiRIKQFVgZp.pgp
Description: PGP signature
_______________________________________________ Nmh-workers mailing list Nmh-workers(_at_)nongnu(_dot_)org https://lists.nongnu.org/mailman/listinfo/nmh-workers