Help with files and spaces with shell script

[Cameron Simpson]

On 16Sep2007 20:04, Jacques B. <jjrboucher at gmail.com> 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 at 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