[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: builtin echo command redirection misbehaves in detached scripts when

From: Stephane Chazelas
Subject: Re: builtin echo command redirection misbehaves in detached scripts when terminal is closed
Date: Mon, 10 Sep 2007 17:39:09 +0100
User-agent: Mutt/1.5.16 (2007-06-11)

On Mon, Sep 10, 2007 at 11:57:34AM -0400, Chet Ramey wrote:
> Andreas Schwab wrote:
> > Chet Ramey <address@hidden> writes:
> > 
> >> What's needed is a portable interface like BSD's fpurge(3).
> > 
> > This is also available from glibc as __fpurge (likewise on Solaris).
> Yes, though I have an aversion to calling functions with a `__' prefix
> from user application code.
> However:
> "These  functions  are  nonstandard  and  not  portable."
> It would be nice to have something standardized.  I can certainly add
> yet another configure test for this -- I just wish I didn't have to.

Note that zsh seems to have the same problem as bash here
(except that it uses fwrite + fputc instead of printf).

The problem I saw with ksh93 seems to be unrelated as ksh93
doesn't seem to be using stdio.

Dmitry, your t.c in the debian report gives:

On Solaris 8:

$ ./t
signal handler called, sig=2
error at num_bytes=15352
fputs: Interrupted system call
writer: num_bytes=80000 num_lines=10000
reader: num_bytes=74888 num_lines=9361
reader: number of missing bytes: 5112

On HPUX 11.11:

$ ./t
signal handler called, sig=2
error at num_bytes=16376
fputs: Interrupted system call
fclose: Interrupted system call
reader: num_bytes=71816 num_lines=8977
reader: number of missing bytes: 8184

So they don't seem to care either to retry and send the data
if the first write() fails.

With dietlibc:

$ ./t
signal handler called, sig=2
writer: num_bytes=80008 num_lines=10001
writer: expected num_bytes=80000 but was 80008
reader: num_bytes=80007 num_lines=10000
reader: number of missing bytes: -7

And dietlibc behaves the same as glibc patched with your
(Dmitry's) change upon the fflush. That is bash would misbehave
the same if linked against dietlibc.

I've also verified that if I revert your change and recompile
the glibc, bash's (and zsh's) problem goes away, so that would
confirm if needed be that it was that fix that introduced the
change in behavior.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]