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

[Jason Vas Dias]

Thanks Andreas -

I guess your answer mostly explains my issue - except for one thing:
>>  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.

This was really the point of my question - why, if escaping is permitted and
an escape is shell syntax,  does word-splitting not honor escapes, ESPECIALLY
if the character being escaped is a character in $IFS ?

Would it be much work to make word-splitting honor escapes ?

Why is this issue of escaping not being enabled during word-splitting
not documented anywhere ?

Thanks & Regards,
Jason

On Sun, Jul 29, 2012 at 9:05 PM, Andreas Schwab <address@hidden> wrote:
> Jason Vas Dias <address@hidden> 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, address@hidden
> GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
> "And now for something completely different."