[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Andreas Schwab
Subject: Re: why must non-standard $IFS members be treated so differently ?
Date: Sun, 29 Jul 2012 22:05:30 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux)

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'
$ 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 Schwab, address@hidden
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

reply via email to

[Prev in Thread] Current Thread [Next in Thread]