Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 12 May 1998 13:10:04 -0700 (PDT)
From:      woods@zeus.leitch.com (Greg A. Woods)
To:        freebsd-bugs@FreeBSD.ORG
Subject:   Re: bin/6557: /bin/sh && IFS
Message-ID:  <199805122010.NAA26561@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: woods@zeus.leitch.com (Greg A. Woods)
To: Martin Cracauer <cracauer@cons.org>
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: bin/6557: /bin/sh && IFS
Date: Tue, 12 May 1998 16:07:30 -0400 (EDT)

 [ 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.
 
 >  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:
 
 (the Open Group's "Single UNIX Specification" says essentially the same
 things too...)
 
 
                Copyright c 1991 IEEE.  All rights reserved.
       This is an unapproved IEEE Standards Draft, subject to change.
 
  Part 2: SHELL AND UTILITIES                                 P1003.2/D11.2
 
 . . .
 
  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.
 
  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
 
  BEGIN_RATIONALE
 
  3.6.5.1  Field Splitting Rationale. (This subclause is not a part of
           P1003.2)
 
  The operation of field splitting using IFS as described in earlier drafts
  was based on the way the KornShell splits words, but is incompatible with
  other common versions of the shell.  However, each has merit, and so a
  decision was made to allow both.  If the IFS variable is unset, or is
  <space><tab><newline>, the operation is equivalent to the way the
  System V shell splits words.  Using characters outside the
  <space><tab><newline> set yields the KornShell behavior, where each of
  the non-<space><tab><newline> characters is significant.  This behavior,
  which affords the most flexibility, was taken from the way the original
  awk handled field splitting.
 
  The (3) rule can be summarized as a pseudo ERE:                            1
 
        (s*ns*|s+)                                                           1
 
  where s is an IFS white-space character and n is a character in the IFS    1
  that is not white space.  Any string matching that ERE delimits a field,   1
  except that the s+ form does not delimit fields at the beginning or the    1
  end of a line.  For example, if IFS is <space><comma>, the string          1
 
        <space><space>red<space><space>,<space>white<space>blue              1
 
  yields the three colors as the delimited fields.                           1
 
  END_RATIONALE
  
 
 -- 
 							Greg A. Woods
 
 +1 416 443-1734      VE3TCP      <gwoods@acm.org>      <robohack!woods>
 Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>

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?199805122010.NAA26561>