On Mon, Sep 10, 2007 at 12:05:57AM +0200, Aurelien Jarno wrote:
[...]
> >>> bash -c 'echo a; echo b > a' >&-
> >>>
> >>> is enough for me to reproduce the problem.
[both "a" and "b" seen in file "a".]
> >> Guess you have a buggy libc, then.
> > [...]
> >
> > I wouldn't be surprised if it has to
On Mon, Sep 10, 2007 at 11:56:33AM +0400, Dmitry Potapov wrote:
> On Sun, Sep 09, 2007 at 10:18:07PM +0100, Stephane Chazelas wrote:
> > Now, I'm not sure if we can say that the new glibc behavior
> > observed is bogus (other than it's different from the behavior
> > observed in all the libcs I tri
On Mon, Sep 10, 2007 at 02:17:41PM +0400, Dmitry Potapov wrote:
[...]
> On Mon, Sep 10, 2007 at 09:08:33AM +0100, Stephane Chazelas wrote:
> > thanks for replying, I gave a list in another email. I tried on
> > Solaris 7 and HPUX and both seem to flush the buffer upon an
> > unsuccessful fflush()
>
On Sun, Sep 09, 2007 at 10:18:07PM +0100, Stephane Chazelas wrote:
> Now, I'm not sure if we can say that the new glibc behavior
> observed is bogus (other than it's different from the behavior
> observed in all the libcs I tried with).
What libc have you tried?
To me, the new behavior makes much
On Mon, Sep 10, 2007 at 12:05:57AM +0200, Aurelien Jarno wrote:
> > I wouldn't be surprised if it has to do with the fix to debian
> > bug #429021. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=429021
> > (I'm CCing Dmitry who is the author of that change according to
> > bugs.debian.org)
> >
>
Hi Stephane,
On Mon, Sep 10, 2007 at 09:08:33AM +0100, Stephane Chazelas wrote:
> thanks for replying, I gave a list in another email. I tried on
> Solaris 7 and HPUX and both seem to flush the buffer upon an
> unsuccessful fflush()
I see... I wonder how they work in regard of my original problem
Dmitry Potapov wrote:
>
> Unfortunately, you are right. I did not foresee that some shells may use
> "dup2(open("file.txt"), fileno(stdout))". It is a dirty hack, which may
> cause some other problems. Frankly, I am a bit surprised that bash uses
> printf instead of write(2). BTW, you cannot use
Hello Stephane,
I was wrong about suggestion freopen("/dev/stdout") in my previous mail.
It cannot be used to redirect stdout.
Regards,
Dmitry
Chet Ramey <[EMAIL PROTECTED]> writes:
> What's needed is a portable interface like BSD's fpurge(3).
This is also available from glibc as __fpurge (likewise on Solaris).
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
> What's needed is a portable interface like BSD's fpurge(3).
Gnulib provides this[1]. Maybe you should consider using
gnulib to enhance the portability of future versions of bash.
[1] http://www.gnu.org/software/gnulib/MODULES.html#module=fpurge
--
Eric Blake
--
View this message in contex
Andreas Schwab wrote:
> Chet Ramey <[EMAIL PROTECTED]> 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 co
On Mon, Sep 10, 2007 at 11:57:34AM -0400, Chet Ramey wrote:
> Andreas Schwab wrote:
> > Chet Ramey <[EMAIL PROTECTED]> 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
On Mon, Sep 10, 2007 at 05:39:09PM +0100, Stephane Chazelas wrote:
> Dmitry, your t.c in the debian report gives:
>
> On Solaris 8:
[...]
> On HPUX 11.11:
[...]
>
> So they don't seem to care either to retry and send the data
> if the first write() fails.
Yes, it seems they purge all data in the
On Mon, Sep 10, 2007 at 09:25:26PM +0400, Dmitry Potapov wrote:
[...]
> > With dietlibc:
> >
> > $ ./t
> > signal handler called, sig=2
> > writer: num_bytes=80008 num_lines=10001
> > writer: expected num_bytes=8 but was 80008
> > reader: num_bytes=80007 num_lines=1
> > reader: number of m
14 matches
Mail list logo
