Re: why must non-standard $IFS members be treated so differently ?

[Andreas Schwab]

Jason Vas Dias <jason.vas.dias@gmail.com> writes:

> Thanks Dan -
>  The plot thickens - Yes, you're right, I had $IFS mistakenly set to ':' in 
> the
>   shell in which I ran 'count_args' . Without this IFS setting, I get
> a count of 4:
>   $ env -i PATH=/bin:/usr/bin HOME=${HOME} /bin/bash --norc
>   $ count_args 1 2 3\ 4
>   4
>   $ IFS=: count_args 1 2 3\ 4
>   3
>  This to me is strange , as I've asked bash not to use ' ' as a
> delimiter, when $IFS==: , but it is doing so !

IFS does not change the shell syntax.  It only controls field splitting
as applied to the result of expansions.  Compare:

$ bash -c 'IFS=:; echo a:b:c'
a:b:c
$ bash -c 'IFS=:; a=a:b:c; echo "$a" $a'
a:b:c a b c
$ bash -c 'IFS=:; a=a:b:c; b=$a; echo "$b" $b'
a:b:c a b c

In the last example the assignment "b=$a" doesn't undergo field
splitting, so the colons are still preserved.

>  And shouldn't '3\ 4' be a single string in any case, regardless of IFS ?

It is.  But if field splitting is applied to it it will be split in two
words when $IFS contains a space.

>  If word splitting is not doing any escaping, why not - shouldn't it
> be doing so?

Escape characters are part of the shell syntax.  They are never special
when they result from expansions, unless they are reinterpreted as shell
input through eval.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."