why does sh do this

Andrew H. Marrinson andy at xwkg.Icom.Com
Wed Jun 5 07:40:26 AEST 1991


pdg at cs.uow.edu.au (Peter Gray) writes:

>I have a question regarding sh and IFS.

> [...]

>The SUNOS man page for sh says

>     After parameter and command  substitution,  the  results  of
>     substitution  are scanned for internal field separator char-
>     acters (those found in IFS) and split  into  distinct  argu-
>     ments  where such characters are found.  Explicit null argu-
>     ments ("" or '')  are  retained.   Implicit  null  arguments
>     (those  resulting  from  parameters that have no values) are
>     removed.

Yes, so does the System V man page.  However, earlier, under Commands
it says: ``A simple command is a sequence of non-blank words separated
by blanks.''  And, just above that, under Definitions, it says: ``A
blank is a tab or a space.''  All of this takes place before parameter
and command substitution.  The IFS separators are a different
mechanism, taking place after parameter and command substitution.

>How does sh actually use IFS??? Why doesn't altering IFS alter
>the interpretation of subsequent lines in a script?

It uses it in addition to blank and tab substitution, and at a
different point in processing the command line.  In particular, it
performs splitting with IFS after parameter substition, which explains
why space and tab are in IFS, even though, from the above, it might
seem redundant.  For example, with the default IFS, consider this
sequence of commands:

	foo='xxx yyy'
	echo $foo

The echo here has two arguments, not one, because the splitting by IFS
takes place after parameter substition.  If IFS were changed to :, it
would have just one argument, but then changing foo to xxx:yyy would
cause echo $foo to have two arguments again.

This was weird and somewhat surprising to me, but that it is how it
is.  I didn't understand what was going on until I went back and read
the manual entry, but there it is, clear as mud!
--
		Andrew H. Marrinson
		Icom Systems, Inc.
		Wheeling, IL, USA
		(andy at icom.icom.com)



More information about the Comp.unix.shell mailing list