IFS not fixing carriage returns
Thu May 26 14:30:00 GMT 2011
Eric Blake <eblake <at> redhat.com> writes:
> On 03/25/2011 10:35 AM, Tim McDaniel wrote:
> > Although it's not documented in "man bash" on the latest Cygwin, I did
> > find "set -o igncr" and it seems to work well.
> I documented it in the cygwin bash release notes, so it is in
> /usr/share/doc/Cygwin/bash.README. Patches welcome if you want to see
> it somewhere else like the man page, because that takes more effort.
> > But I'm just curious about why my first attempt didn't work.
> IFS only affects word splitting _after words have been parsed and
> expansions performed_. Bash does _not_ ignore CR in the input stream
> while parsing words, regardless of the IFS settings. Let's use a
> simpler example:
> If you set IFS=., then echo a.b will still only echo the one word "a.b"
> and not split into two words "a" and "b", because '.' is not special in
> determining word boundaries (a.b is a single word), and there was no
> expansion going on.
> And it would be prohibitively expensive to make shells honor random IFS
> while parsing out words, so bash _only_ uses space, tab, and newline to
> determine word boundaries, not carriage return.
> That's why igncr is more powerful than IFS - it strips the CR prior to
> the point that bash is even trying to parse the line into words.
Can I urge this option be added into the upstream bash, so it's available under
Linux versions too? I want to run scripts that work with some text files that
have come from Windows and it would be extremely useful. If I use it now
however, in bash version 4.0.33(1)-release (i486-pc-linux-gnu) I get:
+ set -o igncr
set: 1: Illegal option -o igncr
So the script is not portable between Windows and Linux.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
More information about the Cygwin