> Also, you should never name unexported variables with UPPER CASE names. > > By convention, exported variables haver UPPER CASE names and local variables > have lower case names. By following that convention your script variable > semantics are more obvious. Thanks. I wasn't aware of this. But makes sense. By avoiding upper case variable names in your script unless it's one you will be exporting, you will not accidentally overwrite an environment variable which by convention uses upper case names. I've been toying with BASH scripting for a few years and did some light programming prior to that. I purchased a book from O'Reilly last year called "Learning the bash Shell" 3rd Edition. In that book the author recommended using UPPERCASE variable names when declaring constants/read-only variables in your scripts. It sounded like a good idea so I adopted it. But your explanation of why you shouldn't makes sense. Granted I haven't written any scripts where I've exported a variable to the environment shell so it hasn't been an issue. I noticed that as long as you don't source the script the risk will only apply to your script and sub-processes of your script. So as long as you know your script and the commands that it uses well enough you should be safe. But your reason for not using it is a prudent one worth adopting. Is there an acceptable practice for constants/read-only variables? Jacques B. > > However, there is a more important reason for this practice: inherited > variables are _automatically_ exported to subcommands, even if your script > changes them. > > So, consider that you call come utility command that relies on an > exported variable of which you were unaware. This is almost certainly > the case at some point. Suppose that variable is called FOO and your > script does this: > > FOO=bah > call a utility that quietly expects $FOO to mean something > > and _does_ _not_ export it. Well, that might seem ok, and if there is no > $FOO already in the environment it will be ok; $FOO will remain local to > your script, not apassed to the utility. > > Now further suppose that the system environment _does_ set $FOO and export it > for some perfectly benign reason - perhaps $FOO says where some device lives. > _Now_, your change to $FOO _is_ exported to the utility, which may now > do something insane because your setting has no relationship to the > utilityies expectation for $FOO. > > By always using lower case names for unexported variables you make this > scenario much much less likely. > > It is a serious issue, and little thought of. > > Cheers, > -- > Cameron Simpson <cs@xxxxxxxxxx> DoD#743 > http://www.cskk.ezoshosting.com/cs/ > > Get with it - if you think your genes are worth propagating, you're going to > have to kick butt. - Steve Sanderson, in reference to dating > > -- > fedora-list mailing list > fedora-list@xxxxxxxxxx > To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list > -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
