Re: [bash-4.0 executes command without newline]

[Arindam Sarkar - Sun Microsystems]

Hi Chet,
  My apologies for the delay in replying to your email.

Chet Ramey wrote:
> On 12/16/09 7:59 AM, Arindam Sarkar - Sun Microsystems wrote:
>   
> > Configuration Information [Automatically generated, do not change]:
> > Machine: sparc
> > OS: solaris2.11
> > Compiler: /ws/onnv-tools/SUNWspro/SS12/bin/c99
> > Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='sparc'
> > -DCONF_OSTYPE='solaris2.11' -DCONF_MACHTYPE='sparc-sun-solaris2.11'
> > -DCONF_VENDOR='sun' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -Xc
> > -features=extinl,extensions -xprefetch=auto -xbuiltin=%none -xnorunpath
> > -xcsi -xinline=%auto -xustr=ascii_utf16_ushort -xF=%none
> > -xthreadvar=%all -xspace -xldscope=symbolic -KPIC -mt -D_REENTRANT
> > -D__EXTENSIONS__=1 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
> > -D_XOPEN_SOURCE=600 -D_XPG6 -D_POSIX_PTHREAD_SEMANTICS
> > -D_POSIX_C_SOURCE=200112L -D__XOPEN_OR_POSIX -D_STRICT_STDC
> > -D_STRICT_STDC__ -D_STDC_C99 -D_ISOC99_SOURCE -D__C99FEATURES__
> > -DSOLARIS -m32 -xvis=yes -xmemalign=8i -xregs=appl -xtarget=ultra2
> > -xarch=sparcvis -xchip=ultra2 -xO4 -s -DSHELL -DHAVE_CONFIG_H
> > -DSOLARIS   -I.  -I. -I./include -I./lib  -DTEXT_DOMAIN= 
> > -I/net/train/builds/arindam/6811876/sfwnv/proto/root_sparc/usr/include 
> > -I/net/train/builds/arindam/6811876/sfwnv/proto/root_sparc/usr/sfw/include 
> > -I/net/train/b!
> > uilds/arindam/6811876/sfwnv/proto/root_sparc/usr/include    -Xc
> > -features=extinl,extensions -xprefetch=auto -xbuiltin=%none -xnorunpath
> > -xcsi -xinline=%auto -xustr=ascii_utf16_ushort -xF=%none
> > -xthreadvar=%all -xspace -xldscope=symbolic -KPIC -mt -D_REENTRANT
> > -D__EXTENSIONS__=1 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
> > -D_XOPEN_SOURCE=600 -D_XPG6 -D_POSIX_PTHREAD_SEMANTICS
> > -D_POSIX_C_SOURCE=200112L -D__XOPEN_OR_POSIX -D_STRICT_STDC
> > -D_STRICT_STDC__ -D_STDC_C99 -D_ISOC99_SOURCE -D__C99FEATURES__
> > -DSOLARIS -m32 -xvis=yes -xmemalign=8i -xregs=appl -xtarget=ultra2
> > -xarch=sparcvis -xchip=ultra2 -xO4 -s
> > uname output: SunOS train 5.11 snv_125 sun4u sparc SUNW,Sun-Fire-V890
> > Machine Type: sparc-sun-solaris2.11
> >
> > Bash Version: 4.0
> > Patch Level: 28
> > Release Status: release
> >
> > Description:
> >    bash executes command without newline
> >    This bug was assumed to be fixed with the intregation
> >    of bash-4.0, but it is still reproducible.
> >     
>
> This is not a bug.  Shells dating back to v7 have interpreted EOF as a
> token delimiter equivalent to newline.  Posix standardizes this behavior.
>   
 I had gone through the standard and found this: 

There is one place in the "Token Recognition" section in the "Shell
Command Language" says:

-------------
If the end of input is recognized, the current token shall be delimited. 
If there is no current token, the end-of-input indicator shall be 
returned as the token.
-------------

So, the EOF is a delimitor and the token probably can be processed.
However, we are being hung up. There is another section in the
General Terminal interface says:

-------------
Modem Disconnect

If a modem disconnect is detected by the terminal interface for a 
controlling terminal, and if CLOCAL is not set in the c_cflag field for 
the terminal (see Control Modes ), the SIGHUP signal shall be sent to 
the controlling process for which the terminal is the controlling 
terminal. Unless other arrangements have been made, this shall cause the 
controlling process to terminate (see exit()). Any subsequent read from 
the terminal device shall return the value of zero, indicating 
end-of-file; see read(). Thus, processes that read a terminal file and 
test for end-of-file can terminate appropriately after a disconnect. If 
the EIO condition as specified in read() also exists, it is unspecified 
whether on EOF condition or [EIO] is returned. Any subsequent write() to 
the terminal device shall return -1, with errno set to [EIO], until the 
device is closed.
--------------

So the controlling process would be able to be terminated by SIGHUP.
Since EOF would be the consequence of a disconnect, I'd rather feel
that it would be okay to discard the pending characters. In fact,
if shell is reading terminal in ICANON mode, the pending characters
are discarded in the terminal driver when disconnected (ie read(2)
wouldn't read the pending characters but read(2) returns 0).

Could you  let me know the rationale on the 'standardized' behavior that
you pointed and which exist in Posix ?


thanks
-Arindam
> Chet
>