On 16Sep2007 20:04, Jacques B. <jjrboucher@xxxxxxxxx> wrote: | By the way I noted a typo in my suggestion. In the beginning I use | ORIGINAL_IFS for my variable, but for the suggested last line of the | script I had IFS=$ORIGINAL. That should have been IFS=$ORGINAL_IFS. I tend to just say "oIFS" myself. Less typo-prone, more readable. 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. 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
