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
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 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
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
is message in context:
http://www.nabble.com/builtin-echo-command-redirection-misbehaves-in-detached-scripts-when-terminal-is-closed-tf4409627.html#a12594005
Sent from the Gnu - Bash mailing list archive at Nabble.com.
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
Hello Stephane,
I was wrong about suggestion freopen("/dev/stdout") in my previous mail.
It cannot be used to redirect stdout.
Regards,
Dmitry
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
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
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)
> >
>
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 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 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 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
Stephane Chazelas a écrit :
> On Sun, Sep 09, 2007 at 10:08:14PM +0200, Andreas Schwab wrote:
>> Stephane Chazelas <[EMAIL PROTECTED]> writes:
>>
>>> On Sun, Sep 09, 2007 at 07:10:59PM +0100, Stephane Chazelas wrote:
>>> [...]
What OS and version of glibc? I do get the error message but I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Stephane Chazelas on 9/9/2007 11:17 AM:
> can be reproduced with 3.2.25 and with:
>
> bash -c 'trap "" PIPE; sleep 1; echo a; echo b > a' | :
>
> It seems to be down to the usage of stdio.
Indeed. I raised this very bug several months
The change is far from trivial or harmless, if it was intended. I had to
rebuild a custom server I run in a hurry because it was flooding an IRC
channel with log lines a backend bash script sent to stderr. And I can
think of plenty of ways to trash files with this bug.
Anyway, thanks a lot Sté
On Sun, Sep 09, 2007 at 10:08:14PM +0200, Andreas Schwab wrote:
> Stephane Chazelas <[EMAIL PROTECTED]> writes:
>
> > On Sun, Sep 09, 2007 at 07:10:59PM +0100, Stephane Chazelas wrote:
> > [...]
> >> What OS and version of glibc? I do get the error message but I
> >> get both a and b in the file.
Stephane Chazelas <[EMAIL PROTECTED]> writes:
> On Sun, Sep 09, 2007 at 07:10:59PM +0100, Stephane Chazelas wrote:
> [...]
>> What OS and version of glibc? I do get the error message but I
>> get both a and b in the file.
>>
>> That was on Linux, glibc 2.6.1.
> [...]
>
> Actually,
>
> bash -c 'ec
On Sun, Sep 09, 2007 at 08:44:25PM +0200, Pierre-Philippe Coupard wrote:
[...]
> - akula, my bleeding edge box, is a Debian-unstable box upgraded yesterday
> sept 8, 2007. It runs linux-2.6.17.7, libc6-2.6.1
>
> - kilo, my most up-to-date box where bash still seems to behave properly
> with regar
Stephane Chazelas <[EMAIL PROTECTED]> writes:
> That was on Linux, glibc 2.6.1.
Same.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now fo
Andreas Schwab wrote:
I get this:
$ bash -c 'trap "" PIPE; sleep 1; echo a; echo b > a' | :
bash: line 0: echo: write error: Broken pipe
and the file contains only one line.
Andreas.
I did more tests, and this is what I came up with:
- akula, my bleeding edge box, is a Debian-unstable box
On Sun, Sep 09, 2007 at 07:10:59PM +0100, Stephane Chazelas wrote:
[...]
> What OS and version of glibc? I do get the error message but I
> get both a and b in the file.
>
> That was on Linux, glibc 2.6.1.
[...]
Actually,
bash -c 'echo a; echo b > a' >&-
is enough for me to reproduce the proble
On Sun, Sep 09, 2007 at 07:36:52PM +0200, Andreas Schwab wrote:
> Stephane Chazelas <[EMAIL PROTECTED]> writes:
>
> > Bonjour Pierre-Philippe,
> >
> > can be reproduced with 3.2.25 and with:
> >
> > bash -c 'trap "" PIPE; sleep 1; echo a; echo b > a' | :
>
> I get this:
>
> $ bash -c 'trap "" PI
Stephane Chazelas <[EMAIL PROTECTED]> writes:
> Bonjour Pierre-Philippe,
>
> can be reproduced with 3.2.25 and with:
>
> bash -c 'trap "" PIPE; sleep 1; echo a; echo b > a' | :
I get this:
$ bash -c 'trap "" PIPE; sleep 1; echo a; echo b > a' | :
bash: line 0: echo: write error: Broken pipe
and
On Sun, Sep 09, 2007 at 04:58:23PM +0200, Pierre-Philippe Coupard wrote:
[...]
>while [ 1 ];do
> echo Test1
> echo Test2 >> file.txt
> sleep 1
>done
>
>As expected, when this script is run in the background (&), the
> console
>slowly fills
Configuration Information [Automatically generated, do not change]:
Machine: i486
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='
27 matches
Mail list logo
