On 17Sep2007 10:44, Jacques B. <jjrboucher@xxxxxxxxx> wrote: | > 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. Yah. You can think of exported variables as being much like constants - they define default parameters for things. | Granted I haven't written any scripts where I've exported a | variable to the environment shell so it hasn't been an issue. No, the issue applies to almost all scripts. The catch is that _you_ do not need to be the person exporting the variable. Supposing you did not know about the $EDITOR variable, and in a script to do with a publication set it to the name of someone. And then in that script invoked an interactive mail command to compose a message or some kind. The mail program will want to run $EDITOR as the user's preferred editor program (its conventional UNIX use) for composing the email. Now, in that scenario you have not exported $EDITOR. But it is quite possible that the system default provide something like "EDITOR=vi". If so, $EDITOR is implicitly exported, and your script has just sabotaged the edit facility in the mail program. | 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. and also the commands those subcommands themselves call, and if any of those commands call a program as the user's discretion (as with $EDITOR above, or via a mailcap file association) then you must magicly know all about any command the user may be caused to be triggered even indirectly. | But your reason for not using it is a prudent one | worth adopting. Is there an acceptable practice for | constants/read-only variables? Maybe start them with an underscore or something equally distinctive? Cheers, -- Cameron Simpson <cs@xxxxxxxxxx> DoD#743 http://www.cskk.ezoshosting.com/cs/ Although dead and in cryonic suspension, Herb Asher was having his own problems. Very close to the Cry-Labs, Incorporated, warehouse a fifty-thousand-watt FM transmitter had been located the year before. For reasons unknown to anyone the cryonic equipment had begun picking up the powerful nearby FM signal. Thus Herb Asher, as well as everyone in suspension at Cry-Labs, had to listen to elevator music all day and all night, the station being what it liked to call a "pleasing sounds" outfit. Right now an all-string version of tunes from _Fiddler on the Roof_ assailed the dead at Cry-Labs . . . - Philip K. Dick, `The Divine Invasion' -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
