Re: Trailing null fields are discarded while leading ones are preserved

[Stahlman Family]

----- Original Message ----- 
From: "Chet Ramey" <chet.ramey@case.edu>
To: "Stahlman Family" <brettstahlman@comcast.net>
Cc: <bug-bash@gnu.org>; <chet@case.edu>
Sent: Wednesday, December 20, 2006 7:26 AM
Subject: Re: Trailing null fields are discarded while leading ones are preserved


> Stahlman Family wrote:
>
> > Ok. I have found an IEEE interpretation for 1003.2-1992 3.6.5
> > (interpretation #98) on the web, and I see that the behavior is correct.
> > The thing that wasn't quite clarified by the clarification is the
> > question: "If IFS serves only to terminate fields, then how is it that,
> > if I add any non IFS character after the final field delimiter, a final
> > field is created, which is "delimited" not by anything in IFS, but by
> > the end of the original (unsplit) word?" The only satisfactory answer I
> > could come up with for this is that the final field in that case is not
> > being *created* by word splitting, but merely retained; i.e., the final
> > field is all that is left of the original word as it existed prior to
> > word splitting. All previous fields were created as a result of
> > encountering an IFS delimiter. Thus, the additional fields are sliced
> > off the front of the original word, and you are left either with nothing
> > (if the final char in the original word was an IFS delimiter) or some
> > portion of the original word otherwise. Is this the correct way to look
> > at it?
>
> More or less.  Alternately, you can think of the NUL at the end of the
> string as an additional field terminator, but one that follows the
> adjacency rules and doesn't create any empty fields.

Ok. Thanks. This, along with the POSIX specification clears things up. Now that I've read the POSIX section on "field splitting", it 
appears to me that the Gnu Bash Manual contradicts POSIX on the subject of treatment of leading IFS whitespace: specifically, the 
following excerpt from the Gnu Bash manual implies that if IFS is unset or equal to the default, then IFS whitespace at the 
beginning of the word will delimit a (leading null) field (since it uses the phrase "any sequence of IFS characters" without making 
the distinction between leading and non-leading characters, which is made for the non default IFS case). The POSIX spec, however, 
makes it clear that IFS whitespace at the beginning of the word is always ignored (rules 1 and 3a), and the implementation is 
consistent with POSIX on this point. I guess the moral of the story is, when in doubt, defer to the POSIX specification...

Excerpt from Gnu Bash Manual: "If IFS is unset, or its value is exactly <space><tab><newline>, the default, then any sequence of IFS 
characters serves to delimit words. If IFS has a value other than the default, then sequences of the whitespace characters space and 
tab are ignored at the beginning and end of the word, as long as the whitespace character is in the value of IFS (an IFS whitespace 
character)."

Brett S.

> Chet
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>        Live Strong.  No day but today.
> Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/