Re: dash: read does not ignore trailing spaces

[Stephane Chazelas <stephane.chazelas@gmail.com>]

2015-12-03 23:17:58 +0000, Stephane Chazelas:
> 2015-12-03 23:04:31 +0000, Stephane Chazelas:
> [...]
> > > Summarising: POSIX states that "each occurrence in the input of an IFS
> > > character that is not IFS white space, along with any adjacent IFS white
> > > space, shall delimit a field". This *may* be interpreted to read that a
> > > final non-whitespace IFS character denotes an empty final field, because
> > > otherwise that final character wouldn't be delimiting any field, but
> > > only terminating one. It's pretty ambiguous, though.
> > [...]
> > 
> > I agree the spec is not very clear
> > http://thread.gmane.org/gmane.comp.shells.bash.bugs/4825
> > http://thread.gmane.org/gmane.comp.shells.bash.bugs/15768
> > 
> > But see this interpretation:
> > https://standards.ieee.org/findstds/interps/1003.1-2001/1003.1-2001-98.html
> > 
> > I can't find the austin-group discussions, but I'm pretty sure
> > I've seen several and Chet is refering to one from 2005 over
> > there.
> [...]
> 
> See also:
> https://groups.google.com/forum/#!topic/comp.unix.shell/krZy2rvnv2g
> (Geoff is from the OpenGroup).
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=512438
> I actually was the one raising it for posh. I (and the posh
> maintainer apparently) failed to notice that it was applying to
> "read" there as well.
[...]

More:

http://thread.gmane.org/gmane.comp.shells.bash.bugs/9661/focus=9662

Where Chet (I think) refers to:
https://standards.ieee.org/findstds/interps/1003-2-92_int/pasc-1003.2-98.html

The 2005 Austin group discussion can be seen on the web archive:
http://web.archive.org/web/20050301075813/http://www.opengroup.org/austin/mailarchives/

One article there was forwarded to the zsh mailing list:
http://www.zsh.org/mla/workers/2005/msg00306.html
(but not acted upon)

Which leads to https://www.opengroup.org/austin/aardvark/latest/xcubug2.txt
confirming that
https://standards.ieee.org/findstds/interps/1003.1-2001/1003.1-2001-98.html
is contemporary and a follow-up of that 2005 discussion.

-- 
Stephane