Re: Completion bug introduced in 3.0.3

[Zoltan Hidvegi <hzoli@xxxxxxxxxxxxxxx>]

> On Jul 2, 12:51am, Zoltan Hidvegi wrote:
> } Subject: Re: Completion bug introduced in 3.0.3
> }
> } > Another thing:  I use a TCL script that sets its stdout stream to
> } > non-blocking.  This somehow affects zsh, as all interactive commands
> } > started after the TCL script (like "ftp" or "more") immediately terminate
> 
> I meant to mention this before ...
> 
> It's an extremely bad idea for any program to set a tty device for non-
> blocking I/O.  This doesn't "somehow affect zsh," it affects the modes
> of the file descriptor associated with the tty; which happens to be a
> dup of the one zsh continues using for future processes, and therefore
> it affects those processes as well.

Perhaps I have a different tclsh, which resets the mode when it exits.  But
this can be tested with this little C program (nonblock.c):

#include <unistd.h>
#include <fcntl.h>

int
main(int argc, char *argv[])
{
    fcntl(0, F_SETFL, O_NONBLOCK);
    exit(0);
}

It sets stdin, but on a terminal this is the same as stdout.  Bash, ksh
and pdksh does seem to reset stdin on startup and before each prompt if
-s (shinstdin in zsh) is set, zsh doesn't.  POSIX says that blocking
input should be set on shell startup, but it does not seems to be
necessary to reset blocking mode after every application.  But blocking
mode should always be set when stdin is used, not only when shinstdin is
set.  Bash violates this:

nonblock; bash -c 'read foo; echo $foo'

does not set blocking read.  AT&T ksh93 does set blocking read here.
pdksh too, but pdksh always sets blocking mode, regardless of the use of
stdin.

Here is the relevant part of the standard (from www.rdg.opengroup.org):

    The standard input will be used only if one of the following is true: 

      o The -s option is specified. 

      o The -c option is not specified and no operands are specified. 

      o The script executes one or more commands that require input from
        standard input (such as a read command that does not redirect its
        input). 

    [...]

    If the standard input to sh is a FIFO or terminal device and is set to
    non-blocking reads, then sh will enable blocking reads on standard
    input. This will remain in effect when the command completes.  (This
    concerns an instance of sh that has been invoked, probably by a
    C-language program, with standard input that has been opened using the
    O_NONBLOCK flag; see open() in the XSH specification. If the shell did
    not reset this flag, it would immediately terminate because no input
    data would be available yet and that would be considered the same as
    end-of-file.)

I think that the AT&T ksh behaviour is the most conforming and most
logical one.

Zoltan