slight OT: shell-script programing style -- origins and change?

[Linda Walsh-3]

This is not exactly bash specific, but I was looking at a shell script
recently and they use the age old convention of using upper case
names for all their shell variables.

At one point I remember this being common practice, but today, ALL
CAPS LOOKS LIKE YOU ARE YELLING OR ARE A FOUR OR FIVE YEAR OLD WHO
DOESN'T KNOW HOW TO WRITE.  (Blech, sorry..).  If you thought I was
yelling, I made my point.

I was wondering where this convention came from  and  if it's still
considered 'the gold standard' of shell programming.

Personally, there are some legacy variables, maybe system wide
environment variables like USER, and HOME, that make sense and don't
"feel" wrong in allcaps, but for user programs, I'm not sure
allcaps is all that desirable.  Maybe for 'constants'? Even there,
$phi, looks just fine or $pi...

What do others think, (or is there a better venue for this
question?)  

I thought I 'd ask here first, since bash seems to be
the most advanced and most widely used descendent of the original
Bourne shell, and those most interested in that shell might be
on this list...but that could easily be a misperception on my part.

-linda

[Stephane Chazelas]

2009-10-25, 12:05(-07), Linda Walsh:
> This is not exactly bash specific, but I was looking at a shell script
> recently and they use the age old convention of using upper case
> names for all their shell variables.
[...]

By convention, _environment_ variables are upper-case, which helps
in a shell script to distinguish them with ordinary variables. I
would consider shell scripts with all upper-case variables to be
poorly written, and I agree with the fact that it looks like
yelling and is less easy to read.

It's OK to use upper-case for environment variables as you
generally want to have the environment as small as possible.

> What do others think, (or is there a better venue for this
> question?)  

The comp.unix.shell newsgroup would be the best place.

> I thought I 'd ask here first, since bash seems to be
> the most advanced and most widely used descendent of the original
> Bourne shell, and those most interested in that shell might be
> on this list...but that could easily be a misperception on my part.
[...]

I wouldn't say it's not the most advanced (compared to zsh and
maybe ksh93), but it's more stable than those 2, and more
focused than zsh on being standard conformant, and have fewer
design awkardnesses than ksh93 (though it did copy a lot from
that shell).

It's also the official shell of the GNU project, which is
probably the main reason for its popularity (as that means it's
installed by default on GNU systems and most often the default
user's interactive shell and "sh" implementation there).

--
Stéphane

> ... the age old convention of using upper case names
> for all their shell variables. ...

It reminds some programmers that a '$' is necessary for expansion.
It is somewhat like using all capitals for #define macros in C
(where the expansion is automatic, but still different from other
symbols that aren't macro names.)  Both of these are surreptitious
salves for not having the full LISP conventions for eval and quote.

--

[Marc Herbert-5]

Stephane CHAZELAS a écrit :
> By convention, _environment_ variables are upper-case, which helps
> in a shell script to distinguish them with ordinary variables. I
> would consider shell scripts with all upper-case variables to be
> poorly written, and I agree with the fact that it looks like
> yelling and is less easy to read.

> It's OK to use upper-case for environment variables as you
> generally want to have the environment as small as possible.


This looks indeed like a larger Unix tradition than just a shell script
one. John mentioned C macros, but Sun's Java conventions also recommend
UPPER_CASE for constants. Hasn't Perl the same convention?

Here I purposely confuse globals and constants since they overlap a lot
in practice (the less mutable are the globals, the safer).

In languages lacking actual namespaces it is a useful convention to have
all globals isolated into the well-known "upper case namespace".