[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Help with files and spaces with shell script



> 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 zip com au> 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 redhat com
> To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
>


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]