[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nmh-workers] Environment variables - with or without $?
From: |
valdis . kletnieks |
Subject: |
Re: [Nmh-workers] Environment variables - with or without $? |
Date: |
Thu, 23 Mar 2017 13:46:57 -0400 |
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....
pgpV3f3hdZC9t.pgp
Description: PGP signature