Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 13 May 1998 02:00:02 -0700 (PDT)
From:      Martin Cracauer <cracauer@cons.org>
To:        freebsd-bugs@FreeBSD.ORG
Subject:   Re: bin/6557: /bin/sh && IFS
Message-ID:  <199805130900.CAA03452@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/6557; it has been noted by GNATS.

From: Martin Cracauer <cracauer@cons.org>
To: "Greg A. Woods" <woods@zeus.leitch.com>
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: bin/6557: /bin/sh && IFS
Date: Wed, 13 May 1998 10:57:42 +0200

 In <199805122007.QAA03553@brain.zeus.leitch.com>, Greg A. Woods wrote: 
 > [ On Tue, May 12, 1998 at 08:20:01 (-0700), Martin Cracauer wrote: ]
 > > Subject: Re: bin/6557: /bin/sh && IFS
 > >
 > >  However, it is my current opinion that my fix and bash are
 > >  wrong. Hence I didn't commit it although you are invited to see if it
 > >  fits your needs, it's in the url given above.
 > 
 > It would seem Bash agrees with the real Korn Shell and the real Bourne
 > Shell.  I agree with them too.
 
 Hm, Solaris' ksh and sh don't agree completely (Solaris 2.6/SPARC):
 
 #! /bin/sh
 IFS="   :"
 var="bla:fasel:blubb:"
 for i in foo:bla:fasel:blubb: ; do
     echo val: "'"$i"'"
 done
 echo
 for i in foo:$var ; do
     echo val: "'"$i"'"
 done
 
 
 ~(u2)6% ksh l2
 val: 'foo bla fasel blubb '
 
 val: 'foo'
 val: 'bla'
 val: 'fasel'
 val: 'blubb'
 
 ~(u2)7% sh l2
 val 'foo'
 val 'bla'
 val 'fasel'
 val 'blubb'
 
 val 'foo'
 val 'bla'
 val 'fasel'
 val 'blubb'
 
 But at least they agree that the `for` parameters are subject to IFS
 splitting.  
  
 > >  I still don't have a POSIX reference, but I've been told that POSIX
 > >  specifies that word splitting is to be done during evaluation, not
 > >  during parsing. I think it's obvious that IFS split is part of word
 > >  splitting.
 > 
 > This is the relavent section from POSIX 1003.2 Draft 11.2:
 
 Thanks!
 
 [...] 
 >  3.6.5  Field Splitting
 > 
 >  After parameter expansion (3.6.2), command substitution (3.6.3), and
 >  arithmetic expansion (3.6.4) the shell shall scan the results of
 >  expansions and substitutions that did not occur in double-quotes for
 >  field splitting and multiple fields can result.
 
 Hm, so what are the arguments to `for` (or to any command)?
 
 As far as I can tell, they are
 - not parameter expansion
 - not command substitution
 - not arithmetic expansion
 
 The paragraph above says that only results of these expansions and
 substitutions are subject to field splitting. What kind of
 substitution or expandsion are command arguments a result of?
 
 >  The shell shall treat each character of the IFS as a delimiter and use
 >  the delimiters to split the results of parameter expansion and command
 >  substitution into fields.
 > 
 >      (1)  If the value of IFS is <space>, <tab>, and <newline>, or if it
 >           is unset, any sequence of <space>, <tab>, or <newline>
 >           characters at the beginning or end of the input shall be ignored
 >           and any sequence of those characters within the input shall
 >           delimit a field.  (For example, the input
 > 
 >                 <newline><space><tab>foo<tab><tab>bar<space>
 > 
 >           yields two fields, foo and bar).
 > 
 >      (2)  If the value of IFS is null, no field splitting shall be
 >           performed.
 > 
 >      (3)  Otherwise, the following rules shall be applied in sequence.      1
 >           The term ``IFS white space'' is used to mean any sequence (zero   1
 >           or more instances) of white-space characters that are in the IFS  1
 >           value (e.g., if IFS contains <space><comma><tab>, any sequence    1
 >           of <space> and <tab> characters is considered IFS white space).   1
 > 
 >            (a)  IFS white space shall be ignored at the beginning and end   1
 >                 of the input.                                               1
 > 
 >            (b)  Each occurrence in the input of an IFS character that is    1
 >                 not IFS white space, along with any adjacent IFS white      1
 >                 space, shall delimit a field, as described previously.      1
 > 
 >            (c)  Nonzero-length IFS white space shall delimit a field.       1
 
 The test shell script I gave above contains an interesting matter
 pointed out to me in private email: What happens if a non-white IFS
 value is at the end of something that is subject to field
 splitting? pdksh generates an extra field with an empty value, which
 is IHMO required by these section.
 
 [...]
 
 Martin
 -- 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 Martin Cracauer <cracauer@cons.org> http://www.cons.org/cracauer
   cracauer@wavehh.hanse.de (batched, preferred for large mails)
   Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536
   Paper: (private) Waldstrasse 200, 22846 Norderstedt, Germany

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805130900.CAA03452>