Prev: Is it possible to automatically download new software when it's released?
Next: tee with pipe
From: Lao Ming on 12 Nov 2009 23:32
I had the bright idea of setting IFS="\n" in my while loops as in:

while IFS="\n" read -r FILE

I thought that this worked great for processing directory names or
filenames with spaces in the name. I didn't test it enough but it
seemed to work for several months. Worst of all, I didn't detect this
issue until now.

Now I've just discovered that all folder names that end with the
letter 'n' are not getting processed because, for example,
"Compression" becomes "Compressio" and thus, later, not found.
Looking at the log file, it's definitely the IFS snipping that last
letter off.

So, do I abandon the use of this or am I just using IFS incorrectly or
in a manner that wasn't intended?

Thanks for your help.
From: Janis Papanagnou on 12 Nov 2009 23:49
Lao Ming wrote:
> I had the bright idea of setting IFS="\n" in my while loops as in:
>
> while IFS="\n" read -r FILE
>
> I thought that this worked great for processing directory names or
> filenames with spaces in the name. I didn't test it enough but it
> seemed to work for several months. Worst of all, I didn't detect this
> issue until now.
>
> Now I've just discovered that all folder names that end with the
> letter 'n' are not getting processed because, for example,
> "Compression" becomes "Compressio" and thus, later, not found.
> Looking at the log file, it's definitely the IFS snipping that last
> letter off.
>
> So, do I abandon the use of this or am I just using IFS incorrectly or
> in a manner that wasn't intended?

You may want to use IFS= (i.e. empty)

while IFS= read -r FILE


Janis

>
> Thanks for your help.
From: Seebs on 12 Nov 2009 23:59
On 2009-11-13, Lao Ming <laomingliu(a)gmail.com> wrote:
> I had the bright idea of setting IFS="\n" in my while loops as in:

> while IFS="\n" read -r FILE

The shell does not in general know about "\n".

Try

IFS="
"
.... But don't do it for read, because you don't need it.

Quoting from the bash manpage (but everyone does it the same, so far as
I know):

One line is read from the standard input, or from the file
descriptor fd supplied as an argument to the -u option, and the
first word is assigned to the first name, the second word to the
second name, and so on, with leftover words and their interven-
ing separators assigned to the last name. If there are fewer
words read from the input stream than names, the remaining names
are assigned empty values. The characters in IFS are used to
split the line into words.

The key is "leftover words *and their intervening separators* assigned to
the last name".

So "read -r FILE" should be fine -- it splits nothing.

> Now I've just discovered that all folder names that end with the
> letter 'n' are not getting processed because, for example,
> "Compression" becomes "Compressio" and thus, later, not found.
> Looking at the log file, it's definitely the IFS snipping that last
> letter off.

Interesting! I suppose that's the exception -- the separators BETWEEN
words are preserved, but not those at the end of the line.

You could perhaps use "IFS=/" if you are looking at file names rather
than path names, since file names can't contain a slash.

-s
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
From: Marco Maggi on 13 Nov 2009 02:26
"Lao Ming" wrote:
> I had the bright idea of setting IFS="\n" in my while
> loops as in:
>
> while IFS="\n" read -r FILE

IMHO the correct way to read dangerous file names is with a
nil separator:

read -r -d $'\x00'

of course you have to use programs or wrappers that print
file names with nil separators, too.
--
Marco Maggi
From: pk on 13 Nov 2009 04:23
Lao Ming wrote:

> I had the bright idea of setting IFS="\n" in my while loops as in:
>
> while IFS="\n" read -r FILE
>
> I thought that this worked great for processing directory names or
> filenames with spaces in the name. I didn't test it enough but it
> seemed to work for several months. Worst of all, I didn't detect this
> issue until now.
>
> Now I've just discovered that all folder names that end with the
> letter 'n' are not getting processed because, for example,
> "Compression" becomes "Compressio" and thus, later, not found.
> Looking at the log file, it's definitely the IFS snipping that last
> letter off.
>
> So, do I abandon the use of this or am I just using IFS incorrectly or
> in a manner that wasn't intended?

You are using either "\" or "n" as IFS. To use a literal newline, you need

IFS='
'

or, with shells that support that, IFS=$'\n'
 |  Next  |  Last
Pages: 1 2
Prev: Is it possible to automatically download new software when it's released?
Next: tee with pipe