Jason Vas Dias <jason.vas.d...@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, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."