Date: Tue, 28 Jan 2020 16:02:25 -0500
From: Roger <rogerx....@gmail.com>
Message-ID: <20200128210225.GC12574@localhost4.local>
| 1) Bash internal reserved words cannot be used a variables.
No such rule. Vars are always assigned using xxx= (no reserved words
contain an '=') and accessed using $... (in one form or another) or
occasionally (assign or access, or attribute modification) as an arg
to a command. Reserved words only occur as command names, and can be
used for any other purpose anywhere else. (Consider "echo if" - you
can also do "if=3; if [ $if = 3 ]; then then=7; fi=2; fi" (etc).
Probably not a great idea however.)
| 2) Operating System (Bash or other) reserved variables are all defined as
| capitol letters,
There are no OS reserved variables to consider, only some that are defined
and used by the shell (eg PATH, OPTIND, ...) which you need to avoid using,
unless you're using them as intended. BASH defines a whole set of such
things, though many of them are safe to reuse if you like (you simply lose
the bash defined attribute of that variable, and it becomes ordinary.)
Not all however. There's a list in the man page.
| and all capitol letter variables should be avoided within Bash
That's one way to avoid issues, but quite conservative. You can certainly
use one char (alphabetic - but not '_') var names in upper case.
| Some say variables should be prefixed (or suffixed) to further distinguish
Whatever method you choose, simply avoid those in the list. Sticking
"_VAR" or something on the end of everything looks like it would make the
script unreadable quite quickly, and in any case isn't guaranteed to never
conflict with a bash provided variable.
Incidentally, since sh (all implementations, including bash) has a global
variable namespace, the biggest source of variable name conflicts is
usually with other sh scripts (functions, startup files,
environment variables...) that are incorporated into your script. This one
is hard to deal with, as anything at all is possible, depending upon
the origin of such a thing - and while re-using such a name is unlikely to
harm your script (providing you always initialize vars, and never just assume
they will be null valued/unset before their first assignment), but you can
break other functionality by stealing one of its variables.
Note that no convention you adopt can avoid this problem, as the other
function might have adopted the exact same convention.
| Anybody have any further insight concerning variable naming styles
| aside from what's already written within the documentation?
Use whatever you like, avoiding those listed by the doc as being defined
by bash.
| I could do something like MY_VARIABLE, but then prefixing with "MY_"
| eats up three more chars I could have used for describing my variable
| better.
Not really, it just makes your names longer (there is no length limit for
var names - I have written test cases that use var names thousands of
characters long, omit the spaces and any punctuation, and you could easily
use one of Shakespeare's sonnets as a var name if you wanted. I don't
recommend it.
But it doesn't help for the real problem.
The best way to avoid problems is to avoid making huge scripts (split
different functionality into different scripts) and when you do need
something that is going to be a bit complex, embed it in a function,
and make the variables all be local (which at least protects them from
interfering with other code your function does not call - you need to
handle non-local var names in functions that you do call yourself, as
the global namespace means that you cannot protect those).
kre
