* |& 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).