Re: Include message attributes in print_command?
On 14Jan2009 16:49, Christian Brabandt <cblists@xxxxxxxxxx> wrote:
| On Tue, 13 Jan 2009, Cameron Simpson wrote:
| > And for reasons that require a somewhat
| > wordy explaination, you should never use $UPPERCASE variable names for
| > script-local/non-exprted variables.
|
| Do you mind elaborating on that issue?
Basicly, there are two sides to it. And a third stylistic issue.
Firstly, all the "public" variables that affect program default behaviour
have $UPPERCASE names: $PATH, $MANPATH, $LC_*, $EDITOR, $DISPLAY and so on.
And this is an open ended set: it is not possible to know about all of
them, since they exist for an open ended set of purposes.
Secondly, an inherited variable (i.e inherited from the parent process
==> in the exported set) is _already_ marked for further export.
So suppose you have a suite of programs on the system whose behaviour is
affected by an exported configuration variable $FOO, and the system
configuration sets $FOO in some appropriate way, and you then write a script
which goes:
#!/bin/sh
FOO=1 # note: no "export" command
... use $FOO ...
... call some other stuff, which happens to call one of the sutie
that uses $FOO ...
Even though you have not exported $FOO, the changed value _is_ exported
because it was inherited. So the suite sees FOO=1 and crashes/misbehaves.
Imagine, for a plausible example, the newbie coder who uses $PATH for
something. You can see that that will immediately have a lot of potential
for trouble with anything they then call.
Now, you might be thinking that most programs should know about the
stuff they call, but I would counter that: wrapper programs inherently do
not, existing to do stuff and then call an arbitrary other command;
it's not even true in ordinary circumstances (how many of us worry about
the $PATH, locale or timezone variables, yet these are used by nearly
everything); and finally that updates to a called command command may
introduce dependence on something that was not used when you wrote your
script (glaring example: locale variables, used to make many many programs
change message output language - a relatively recent facility and broadly
irrelevant to the people calling this programs).
This whole system is set up so that, generally, you don't need to know about
all the potential exportable variables - anything else would be a programming
nightmare. If _you_ export a variable, of course you incur some burden to
choose a name unlikely to conflict, but most scripts don't export stuff.
Now, since nobody exports $lowercase variables (we will ignore $http_proxy
and friends, which are unfortunate historic accident because someone didn't
think this through), the safe convention is:
make script locals $lowercase and don't export them
avoid $UPPERCASE, as that is the "exported" namespace
Provided eveyone plays by these rules it all works smoothly. Once people
start polluting the $UPPERCASE namespace everything becomes fragile.
So it should be avoided.
The convention also has the nice property that it matches a common
convention in many languages that "constants" are often named with upper
case names and ordinary variables in lower case.
Cheers,
--
Cameron Simpson <cs@xxxxxxxxxx> DoD#743
http://www.cskk.ezoshosting.com/cs/
Louis Pasteur's theory of germs is ridiculous fiction.
--Pierre Pachet, Professor of Physiology at Toulouse, 1872