* |& loses data (buffering bug?)
@ 2004-02-13 14:15 Vincent Lefevre
2004-02-13 14:33 ` Peter Stephenson
2004-02-13 17:33 ` Vincent
0 siblings, 2 replies; 10+ messages in thread
From: Vincent Lefevre @ 2004-02-13 14:15 UTC (permalink / raw)
To: zsh-users
Hi,
I've noticed that when I use |&, data from either stdout or stderr
(of the first command) are lost. For instance, the output of a
"cvs status |& less" sometimes gives the following:
[...]
===================================================================
File: zeta.c Status: Up-to-date
Working revision: 1.37
Repository revision: 1.37 /CVS/spaces/mpfr/zeta.c,v
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
cvs status: Examining o.alpha
cvs status: Examining o.linux
cvs status: Examining o.solaris
cvs status: Examining o.sunos
cvs status: Examining tests
Sticky Options: (none)
===================================================================
File: tagm.c Status: Up-to-date
[...]
Contents from stdout have been lost here. The problem occurs either
with less or with grep; for instance, a "cvs status |& grep Status"
gave:
[...]
File: replace_all Status: Up-to-date
File: rint.c Status: Up-to-date
File: round_prec.c Status: Up-t
File: set_str.c Status: Up-to-date
File: set_str_raw.c Status: Up-to-date
[...]
instead of:
[...]
File: replace_all Status: Up-to-date
File: rint.c Status: Up-to-date
File: round_prec.c Status: Up-to-date
File: round_raw_generic.c Status: Up-to-date
File: save_expo.c Status: Up-to-date
File: set.c Status: Up-to-date
File: set_d.c Status: Up-to-date
File: set_dfl_prec.c Status: Up-to-date
File: set_exp.c Status: Up-to-date
File: set_f.c Status: Up-to-date
File: set_inf.c Status: Up-to-date
File: set_ld.c Status: Up-to-date
File: set_nan.c Status: Up-to-date
File: set_prc_raw.c Status: Up-to-date
File: set_prec.c Status: Up-to-date
File: set_q.c Status: Up-to-date
File: set_rnd.c Status: Up-to-date
File: set_si.c Status: Up-to-date
File: set_str.c Status: Up-to-date
File: set_str_raw.c Status: Up-to-date
[...]
When I redirect the output of the second command to a file, it seems
that the problem never occurs.
Is it a bug from zsh (I'm using zsh 4.0.9) or from cvs?
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: |& loses data (buffering bug?)
2004-02-13 14:15 |& loses data (buffering bug?) Vincent Lefevre
@ 2004-02-13 14:33 ` Peter Stephenson
2004-02-13 14:43 ` Vincent Lefevre
2004-02-13 17:33 ` Vincent
1 sibling, 1 reply; 10+ messages in thread
From: Peter Stephenson @ 2004-02-13 14:33 UTC (permalink / raw)
To: zsh-users
On Fri, 13 Feb 2004 15:15:05 +0100
Vincent Lefevre <vincent@vinc17.org> wrote:
> Hi,
>
> I've noticed that when I use |&, data from either stdout or stderr
> (of the first command) are lost. For instance, the output of a
> "cvs status |& less" sometimes gives the following:
Have you tried typing `F' in less? It could be the output is jerky and less hasn't actually read to the end of the file.
It's pretty unlikely zsh has been losing data all this time and no-one's
noticed it --- particularly since all zsh has to do is open and redirect
the file descriptors.
--
Peter Stephenson <pws@csr.com> Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK Tel: +44 (0)1223 692070
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
www.mimesweeper.com
**********************************************************************
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: |& loses data (buffering bug?)
2004-02-13 14:33 ` Peter Stephenson
@ 2004-02-13 14:43 ` Vincent Lefevre
2004-02-13 15:00 ` Peter Stephenson
0 siblings, 1 reply; 10+ messages in thread
From: Vincent Lefevre @ 2004-02-13 14:43 UTC (permalink / raw)
To: zsh-users
On 2004-02-13 14:33:59 +0000, Peter Stephenson wrote:
> Have you tried typing `F' in less? It could be the output is jerky
> and less hasn't actually read to the end of the file.
This isn't related to the problem. Anyway, I've tried and this doesn't
solve anything, e.g.
[... lines starting with '?' ...]
? tests/tversion
? tests/tzeta
cvs status: Examining .
Working revision: 1.77
Repository revision: 1.77 /CVS/spaces/mpfr/add.c,v
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
===================================================================
File: add1.c Status: Up-to-date
[...]
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: |& loses data (buffering bug?)
2004-02-13 14:43 ` Vincent Lefevre
@ 2004-02-13 15:00 ` Peter Stephenson
2004-02-13 15:30 ` Vincent Lefevre
0 siblings, 1 reply; 10+ messages in thread
From: Peter Stephenson @ 2004-02-13 15:00 UTC (permalink / raw)
To: zsh-users
On Fri, 13 Feb 2004 15:43:11 +0100
Vincent Lefevre <vincent@vinc17.org> wrote:
> On 2004-02-13 14:33:59 +0000, Peter Stephenson wrote:
> > Have you tried typing `F' in less? It could be the output is jerky
> > and less hasn't actually read to the end of the file.
>
> This isn't related to the problem.
Well, it's certainly *related*, unless I'm really missing the point. Do
you mean the lines that are missing aren't at the end?
> Anyway, I've tried and this doesn't solve anything, e.g.
I don't understand what this example means. Where is the data missing here?
Can you get the same effect with e.g.
perl -e 'open STDERR, ">&STDOUT";
open STDIN, "cvs status|";
exec "less";'
which doesn't involve zsh at all?
--
Peter Stephenson <pws@csr.com> Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK Tel: +44 (0)1223 692070
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
www.mimesweeper.com
**********************************************************************
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: |& loses data (buffering bug?)
2004-02-13 15:00 ` Peter Stephenson
@ 2004-02-13 15:30 ` Vincent Lefevre
2004-02-13 15:44 ` Vincent Lefevre
0 siblings, 1 reply; 10+ messages in thread
From: Vincent Lefevre @ 2004-02-13 15:30 UTC (permalink / raw)
To: zsh-users
On 2004-02-13 15:00:16 +0000, Peter Stephenson wrote:
> On Fri, 13 Feb 2004 15:43:11 +0100
> Vincent Lefevre <vincent@vinc17.org> wrote:
>
> > On 2004-02-13 14:33:59 +0000, Peter Stephenson wrote:
> > > Have you tried typing `F' in less? It could be the output is jerky
> > > and less hasn't actually read to the end of the file.
> >
> > This isn't related to the problem.
>
> Well, it's certainly *related*, unless I'm really missing the point. Do
> you mean the lines that are missing aren't at the end?
No, not at the end, just before or after the
cvs status: Examining o.alpha
cvs status: Examining o.linux
cvs status: Examining o.solaris
cvs status: Examining o.sunos
cvs status: Examining tests
block (that comes from stderr). And I have the same problem with grep
(see my example) -- but this may be normal in this case, as the output
may be fully buffered.
> > Anyway, I've tried and this doesn't solve anything, e.g.
>
> I don't understand what this example means. Where is the data missing here?
Some data from the "cvs status". The example with grep may be better
though (however I can no longer reproduce it).
> Can you get the same effect with e.g.
>
> perl -e 'open STDERR, ">&STDOUT";
> open STDIN, "cvs status|";
>
> exec "less";'
>
> which doesn't involve zsh at all?
It doesn't work either, but this is different: the stderr output is
completely missing.
I've done a "strace -f -o strace.out cvs status |& less" and I got:
[...]
===================================================================
File: zeta.c Status: Up-to-date
Working revision: 1.37
Repository revision: 1.37 /CVS/spaces/mpfr/zeta.c,v
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
cvs status: Examining o.alpha
cvs status: Examining o.linux
cvs status: Examining o.solaris
cvs status: Examining o.sunos
cvs status: Examining tests
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
===================================================================
File: tsub.c Status: Up-to-date
Working revision: 1.40
Repository revision: 1.40 /CVS/spaces/mpfr/tests/tsub.c,v
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
[...]
And strace.out contains:
[...]
4601 write(1, "\nFile: round_raw_generic.c\tStatu"..., 4096) = -1 EAGAIN (Resource temporarily unavailable)
4601 read(6, <unfinished ...>
4622 <... select resumed> ) = 1 (in [5])
4622 read(5, "!\f0\366$\215\237\333IW\v3\177\5\251Rn\5\240\322\267X\373"..., 8192) = 736
4622 select(10, [5 6], [8], NULL, NULL) = 1 (out [8])
4622 write(8, "\242r\340\24\302\356\307\201.\34#5\361\230\222\276?\247"..., 300) = 300
4601 <... read resumed> "\242r\340\24\302\356\307\201.\34#5\361\230\222\276?\247"..., 4096) = 300
4622 select(10, [5 6], [], NULL, NULL <unfinished ...>
4601 write(1, "\n\n Working revision:\t1.53\n R"..., 4096) = -1 EAGAIN (Resource temporarily unavailable)
4601 read(6, <unfinished ...>
4622 <... select resumed> ) = 1 (in [5])
4622 read(5, "\361\22V}jm\2\214\327jT\344LU\213\3241\365\6\375\312\032"..., 8192) = 832
4622 select(10, [5 6], [8], NULL, NULL) = 1 (out [8])
4622 write(8, "\242n\340\224\240\36.KF\262\301_\243\33b\251\321\301v\322"..., 334) = 334
4601 <... read resumed> "\242n\340\224\240\36.KF\262\301_\243\33b\251\321\301v\322"..., 4096) = 334
4622 select(10, [5 6], [], NULL, NULL <unfinished ...>
4601 write(1, "\n Sticky Tag:\t\t(none)\n Stick"..., 4096) = -1 EAGAIN (Resource temporarily unavailable)
4601 read(6, <unfinished ...>
4622 <... select resumed> ) = 1 (in [5])
4622 read(5, "`\302\215\274p?\376s93[\367\20cJ\304Cj\343\f\273e\246\030"..., 8192) = 1104
4622 select(10, [5 6], [8], NULL, NULL) = 1 (out [8])
4622 write(8, "\242n\0A\23\17\5\223\26x\327\357bYZ\10\267\221&\241\3\0"..., 497) = 497
4601 <... read resumed> "\242n\0A\23\17\5\223\26x\327\357bYZ\10\267\221&\241\3\0"..., 4096) = 497
4622 select(10, [5 6], [], NULL, NULL <unfinished ...>
4601 write(1, "\n\n=============================="..., 1350) = 1350
4601 write(2, "cvs status: Examining o.alpha", 29) = 29
4601 write(2, "\n", 1) = 1
4601 write(2, "cvs status: Examining o.linux", 29) = 29
4601 write(2, "\n", 1) = 1
4601 write(2, "cvs status: Examining o.solaris", 31) = 31
4601 write(2, "\n", 1) = 1
4601 write(2, "cvs status: Examining o.sunos", 29) = 29
4601 write(2, "\n", 1) = 1
4601 write(2, "cvs status: Examining tests", 27) = 27
4601 write(2, "\n", 1) = 1
4601 read(6, <unfinished ...>
4622 <... select resumed> ) = 1 (in [5])
4622 read(5, "\340X0MX[TaR!zP\\\300\20h\200\2g\231\270_\251\224\332y"..., 8192) = 688
4622 select(10, [5 6], [8], NULL, NULL) = 1 (out [8])
4622 write(8, "\242v \245 \355y$\243\32064\300?\301\7\224\307\334{\r\v"..., 267) = 267
4601 <... read resumed> "\242v \245 \355y$\243\32064\300?\301\7\224\307\334{\r\v"..., 4096) = 267
4622 select(10, [5 6], [], NULL, NULL <unfinished ...>
4601 write(1, "================================"..., 4096) = -1 EAGAIN (Resource temporarily unavailable)
4601 read(6, <unfinished ...>
4622 <... select resumed> ) = 1 (in [5])
4622 read(5, "N\17$\370\230\207 \304\35\201\261c\333\240\265\21U\207"..., 8192) = 1504
4622 select(10, [5 6], [8], NULL, NULL) = 1 (out [8])
4622 write(8, "\242v\30e\244&gS0|K\346\10@I2\304^\232\4\21\0\0\0\377\377"..., 626) = 626
4601 <... read resumed> "\242v\30e\244&gS0|K\346\10@I2\304^\232\4\21\0\0\0\377\377"..., 4096) = 626
4622 select(10, [5 6], [], NULL, NULL <unfinished ...>
4601 write(1, "\n Sticky Options:\t(none)\n\n===="..., 4096) = -1 EAGAIN (Resource temporarily unavailable)
[...]
With "strace -f -o strace2.out cvs status | cat", the write(1, ...)
calls return 4096 instead of -1.
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: |& loses data (buffering bug?)
2004-02-13 15:30 ` Vincent Lefevre
@ 2004-02-13 15:44 ` Vincent Lefevre
2004-02-13 16:12 ` Peter Stephenson
0 siblings, 1 reply; 10+ messages in thread
From: Vincent Lefevre @ 2004-02-13 15:44 UTC (permalink / raw)
To: zsh-users
On 2004-02-13 16:30:31 +0100, Vincent Lefevre wrote:
> On 2004-02-13 15:00:16 +0000, Peter Stephenson wrote:
> > Can you get the same effect with e.g.
> >
> > perl -e 'open STDERR, ">&STDOUT";
> > open STDIN, "cvs status|";
> >
> > exec "less";'
> >
> > which doesn't involve zsh at all?
>
> It doesn't work either, but this is different: the stderr output is
> completely missing.
In fact, it doesn't do the same thing: STDERR is redirected to the
terminal here. For instance:
greux:...ftware/mpfr-trunk> perl -e 'open STDERR, ">&STDOUT"; open STDIN, "cvs status|"; exec "cat > /dev/null";'
cvs status: Examining .
cvs status: Examining o.alpha
cvs status: Examining o.linux
cvs status: Examining o.solaris
cvs status: Examining o.sunos
cvs status: Examining tests
greux:...ftware/mpfr-trunk>
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: |& loses data (buffering bug?)
2004-02-13 15:44 ` Vincent Lefevre
@ 2004-02-13 16:12 ` Peter Stephenson
2004-02-13 16:17 ` Vincent Lefevre
0 siblings, 1 reply; 10+ messages in thread
From: Peter Stephenson @ 2004-02-13 16:12 UTC (permalink / raw)
To: zsh-users
On Fri, 13 Feb 2004 16:44:09 +0100
Vincent Lefevre <vincent@vinc17.org> wrote:
> On 2004-02-13 16:30:31 +0100, Vincent Lefevre wrote:
> > On 2004-02-13 15:00:16 +0000, Peter Stephenson wrote:
> > > Can you get the same effect with e.g.
> > >
> > > perl -e 'open STDERR, ">&STDOUT";
> > > open STDIN, "cvs status|";
> > >
> > > exec "less";'
> > >
> > > which doesn't involve zsh at all?
>
> In fact, it doesn't do the same thing: STDERR is redirected to the
> terminal here.
You're right, the output from less is being redirected, not the output to
less. Also, the tricks with pipes don't quite match what zsh is doing.
That's something more like:
perl -e 'pipe PIN, POUT;
if (fork) {
close POUT;
open STDIN, "<&PIN";
close PIN;
$_ = <STDIN>;
exec "less";
} else {
close PIN;
open STDOUT, ">&POUT";
open STDERR, ">&POUT";
close POUT;
$| = 1;
print STDOUT "Sync\n";
exec "cvs status";
}'
--
Peter Stephenson <pws@csr.com> Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK Tel: +44 (0)1223 692070
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
www.mimesweeper.com
**********************************************************************
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: |& loses data (buffering bug?)
2004-02-13 16:12 ` Peter Stephenson
@ 2004-02-13 16:17 ` Vincent Lefevre
0 siblings, 0 replies; 10+ messages in thread
From: Vincent Lefevre @ 2004-02-13 16:17 UTC (permalink / raw)
To: zsh-users
On 2004-02-13 16:12:51 +0000, Peter Stephenson wrote:
> You're right, the output from less is being redirected, not the output to
> less. Also, the tricks with pipes don't quite match what zsh is doing.
> That's something more like:
[...]
OK, I can reproduce the problem with that:
[...]
===================================================================
File: acosh.c Status: Up-to-date
Working revision: 1.24
Repository revision: 1.24 /CVS/spaces/mpfr/acosh.c,v
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
===================================================================
File: add.c
Sticky Date: (none)
Sticky Options: (none)
===================================================================
File: tconst_log2.c Status: Up-to-date
Working revision: 1.21
Repository revision: 1.21 /CVS/spaces/mpfr/tests/tconst_log2.c,v
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
===================================================================
[...]
So, this is not a zsh bug.
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: |& loses data (buffering bug?)
2004-02-13 14:15 |& loses data (buffering bug?) Vincent Lefevre
2004-02-13 14:33 ` Peter Stephenson
@ 2004-02-13 17:33 ` Vincent
2004-02-14 11:32 ` Vincent Lefevre
1 sibling, 1 reply; 10+ messages in thread
From: Vincent @ 2004-02-13 17:33 UTC (permalink / raw)
To: zsh-users
On Fri, Feb 13, 2004 at 03:15:05PM +0100, Vincent Lefevre wrote:
> Contents from stdout have been lost here. The problem occurs either
> with less or with grep; for instance, a "cvs status |& grep Status"
> gave:
>
> [...]
> File: replace_all Status: Up-to-date
> File: rint.c Status: Up-to-date
> File: round_prec.c Status: Up-t
> File: set_str.c Status: Up-to-date
> File: set_str_raw.c Status: Up-to-date
> [...]
>
> instead of:
>
> [...]
> File: replace_all Status: Up-to-date
> File: rint.c Status: Up-to-date
> File: round_prec.c Status: Up-to-date
> File: round_raw_generic.c Status: Up-to-date
> File: save_expo.c Status: Up-to-date
> File: set.c Status: Up-to-date
> File: set_d.c Status: Up-to-date
> File: set_dfl_prec.c Status: Up-to-date
> File: set_exp.c Status: Up-to-date
> File: set_f.c Status: Up-to-date
> File: set_inf.c Status: Up-to-date
> File: set_ld.c Status: Up-to-date
> File: set_nan.c Status: Up-to-date
> File: set_prc_raw.c Status: Up-to-date
> File: set_prec.c Status: Up-to-date
> File: set_q.c Status: Up-to-date
> File: set_rnd.c Status: Up-to-date
> File: set_si.c Status: Up-to-date
> File: set_str.c Status: Up-to-date
> File: set_str_raw.c Status: Up-to-date
> [...]
>
> When I redirect the output of the second command to a file, it seems
> that the problem never occurs.
>
> Is it a bug from zsh (I'm using zsh 4.0.9) or from cvs?
That is weird. It looks to me like you might be encountering YALKB
(Yet Another Linux Kernel Bug) :-). I just tested the "cvs status |&
grep Status" command on FreeBSD with zsh-4.1.1 and get no data loss.
You might want to try a different version kernel and see if it still
does it.
Another way to confirm one way or the other, if you have a machine to
test on, is to install FreeBSD and run the same linux binaries of zsh
and cvs on it with the linux_base package installed (for running Linux
binaries) and see if the problem still exists. We discovered that
many of the bugs and instabilities we had wrongly blamed for a long
time on applications such as our in-house CAD system did not exist on
FreeBSD, even running the same binaries, without re-compiling native
to FreeBSD.
We left Linux well over a year ago after almost 10 years of usage
because of all the crashes and weird memory management bugs and all of
the weird problems went away.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: |& loses data (buffering bug?)
2004-02-13 17:33 ` Vincent
@ 2004-02-14 11:32 ` Vincent Lefevre
0 siblings, 0 replies; 10+ messages in thread
From: Vincent Lefevre @ 2004-02-14 11:32 UTC (permalink / raw)
To: zsh-users
On 2004-02-13 11:33:48 -0600, Vincent wrote:
> On Fri, Feb 13, 2004 at 03:15:05PM +0100, Vincent Lefevre wrote:
> > Contents from stdout have been lost here. The problem occurs either
> > with less or with grep; for instance, a "cvs status |& grep Status"
> > gave:
[...]
> > Is it a bug from zsh (I'm using zsh 4.0.9) or from cvs?
>
> That is weird. It looks to me like you might be encountering YALKB
> (Yet Another Linux Kernel Bug) :-).
No, it has been confirmed that this is a cvs bug. For more information,
see bug #228458 on the Debian BTS.
> I just tested the "cvs status |& grep Status" command on FreeBSD
> with zsh-4.1.1 and get no data loss.
The bug occurs only when using ":ext:" over ssh.
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2004-02-14 11:32 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-02-13 14:15 |& loses data (buffering bug?) Vincent Lefevre
2004-02-13 14:33 ` Peter Stephenson
2004-02-13 14:43 ` Vincent Lefevre
2004-02-13 15:00 ` Peter Stephenson
2004-02-13 15:30 ` Vincent Lefevre
2004-02-13 15:44 ` Vincent Lefevre
2004-02-13 16:12 ` Peter Stephenson
2004-02-13 16:17 ` Vincent Lefevre
2004-02-13 17:33 ` Vincent
2004-02-14 11:32 ` Vincent Lefevre
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).