----- Original Message -----
From: "Chet Ramey" <[EMAIL PROTECTED]>
To: "Stahlman Family" <[EMAIL PROTECTED]>
Cc: <bug-bash@gnu.org>; <[EMAIL PROTECTED]>
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 [EMAIL PROTECTED] http://cnswww.cns.cwru.edu/~chet/
_______________________________________________
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
