bug-bash
[Top][All Lists]
Advanced

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

Re: Another mapfile question.


From: Maarten Billemont
Subject: Re: Another mapfile question.
Date: Sun, 7 Aug 2011 07:23:15 +0200

On 05 Aug 2011, at 16:32, Steven W. Orr wrote:

> On 8/5/2011 9:08 AM, Maarten Billemont wrote:
>>> IFS=
>>> aa=()
>>> while read line
>>> do
>>>  aa+=("$line")
>>> done<  fn
>> 
>> You should really put that IFS= on your 'read', so as not to break the 
>> default wordsplitting for the rest of your script:
>> 
> 
> For purposes of giving concise examples on this email list, I wrote it as 
> above. In practice, something like the above construct that modifies IFS 
> would be responsible for restoring IFS.

I'm very much against changing the standard operation of the shell in a broader 
scope than where you need its effect.

old_IFS=$IFS
IFS=$'\n'
while read line
do
    stuff
done < <(fn)
IFS=$old_IFS

The point here is to change IFS for 'read'.  Unfortunately, you're also 
changing it for all of 'stuff'.  Your scope is too broad, and as a result, 
stuff's behavior is non-standard.  Making IFS local-scoped is really the same 
thing, still too broad. You wouldn't notice until you did something with IFS in 
'stuff', and actually did notice the bug in that.  It's dangerous.  Do this:

while IFS= read line
do
    stuff
done < <(fn)

It's much cleaner and it's more correct.

Same goes for set -f hackery.  I'm always against it, because there's no way to 
cleanly scope it, it changes the way the shell works substantially, and there's 
usually constructs that express the logic more correctly.

Attachment: smime.p7s
Description: S/MIME cryptographic signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]