Question on the IFS variable (not a FreeBSD question)

[Manolis Kiagias]

Rakhesh Sasidharan wrote:
>
> Hi,
>
> This isn't really a FreeBSD question. But I figure most people on this
> list would know the answer and so I'm asking. I've tried to get the
> answer out of Google, but I guess I am not asking it the right
> question and so not getting much hits.
>
> I understand that the default value of the IFS variable in bash is
> "space, tab, newline". For a script I am playing around with, I want
> to change IFS to be just newline. I tried the obvious like
>
> IFS="\n"
> -or-
> IFS='\n'
>
> but that doesn't seem to do the trick coz then the letter "n" ends up
> being the separator.
>
> A bit of Google searching got me the solution too. That I must set IFS
> this way:
>
> IFS=$'\n'
>
> I did that, and sure enough things work the way I want!
>
> So my question is this: how come things work when I set IFS to $'\n'
> instead of just plain '\n'? I don't recollect seeing such a way of
> setting variables before, and so I'm curious about it.
>
> TIA,
> Rakhesh
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to
> "freebsd-questions-unsubscribe at freebsd.org"
>

The IFS=$'\n' is, as you found, correct for bash.
See some details for this in the following post:
http://osdir.com/ml/shells.bash.bugs/2004-10/msg00104.html

Do a little experiment (inspired from the post stated above):
#export IFS="\n"
#printf '<%s>\n' "$IFS" | cat -vt
will give <\n> ==> not what you expect
#export IFS='\n'
#printf '<%s>\n' "$IFS" | cat -vt
will give <\n> ==> again, not what you expect
#export IFS=$'\n'
#printf '<%s>\n' "$IFS" | cat -vt
will give
<
>
definitely a new line character (finally...)
I am not certain of the explanation, but from the above it seems to me
the IFS does not evaluate special '\something' characters unless there
is a $ in front. That is, of course, what you would do to get the value
of a shell variable. It seems then these characters need to be evaluated
in the same way.