tneff@bfmny0.UUCP (Tom Neff) (08/19/89)
To heck with mailx(1), this is worse. Why am I just noticing these things now? I have: AT&T UNIX System V/386 3.2.1 /usr/bin/vi.sl 1.1 3.2 06/24/88 40949 AT&T-SF The symptom: Every time you pass a piece of an open file through a filter (e.g., 'spell', 'filter' etc) using the ! <cursor-move> operator, 'vi' leaves the process it used hanging <defunct> in the system, not removed. After enough filter operations, there are no free processes in the system and things grind to a halt. The processes cannot be killed while 'vi' is still running, even with signal 9 from root. Only exiting vi fixes it. What a damned annoyance. Is this known and TBFIAFR? -- "We walked on the moon -- (( Tom Neff you be polite" )) tneff@bfmny0.UU.NET
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (08/20/89)
In article <14562@bfmny0.UUCP>, tneff@bfmny0.UUCP (Tom Neff) writes: > To heck with mailx(1), this is worse. Ha! Nothing is worse than mailx(1), unless you like gratuitous, egregiously wrong features and stupid new bugs. I wish BSD would (could?) release 4.3BSD Mail source as they have done with the network code. > AT&T UNIX System V/386 3.2.1 > [describes vi's failure to reap its dead children after ! operator] > The processes > cannot be killed while 'vi' is still running, even with signal 9 from > root. Only exiting vi fixes it. > "We walked on the moon -- (( Tom Neff > you be polite" )) tneff@bfmny0.UU.NET In ISC 2.0.2 doing something with :! such as ":!sh" or ":!ls" seems to cause vi to do the necessary wait(2)'s. That is, after "!" becomes dead, ":!ls" makes everything wonderful again. The bug was in Microport 2.2-3.0e, and is in the SVR3.2 source tape, so it is not surprising to find it in AT&T's retail product. Vernon Schryver vjs@sgi.com
peter@ficc.uu.net (Peter da Silva) (08/20/89)
In article <40648@sgi.SGI.COM>, vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: > In article <14562@bfmny0.UUCP>, tneff@bfmny0.UUCP (Tom Neff) writes: > > To heck with mailx(1), this is worse. > Ha! Nothing is worse than mailx(1), ... Sure. The version of mailx(1) that comes with the System-3 based Xenixes for Intel's 310/320 boxes. It's way worse. And then there's /bin/mail... -- Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation. Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-' "Optimization is not some mystical state of grace, it is an intricate act U of human labor which carries real costs and real risks." -- Tom Neff
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (08/22/89)
>The symptom: Every time you pass a piece of an open file through a >filter (e.g., 'spell', 'filter' etc) using the ! <cursor-move> operator, >'vi' leaves the process it used hanging <defunct> in the system, I see this same problem here ( Sys V.3.1 on a '386). -- Branch Technology | zeeff@b-tech.ann-arbor.mi.us | Ann Arbor, MI
paddock@mybest.UUCP (pri=-10 Steve Paddock) (08/25/89)
>The symptom: Every time you pass a piece of an open file through a >filter (e.g., 'spell', 'filter' etc) using the ! <cursor-move> operator, >'vi' leaves the process it used hanging <defunct> in the system, Also present in 3B2/600 R3.1.1 -- ------------------------------------------------------------------------------ Steve Paddock uunet!bigtex!mybest!paddock ut-emx!mybest!paddock {attmail|gbsic5|bscaus}!uhous1!paddock
decot@hpisod2.HP.COM (Dave Decot) (08/26/89)
This bug does not appear to be present in any known version of HP-UX. Dave Decot
skwu@boulder.Colorado.EDU (WU SHI-KUEI) (08/26/89)
In article <10861@mybest.UUCP> paddock@mybest.UUCP (pri=-10 Steve Paddock) writes: >>The symptom: Every time you pass a piece of an open file through a >>filter (e.g., 'spell', 'filter' etc) using the ! <cursor-move> operator, >>'vi' leaves the process it used hanging <defunct> in the system, On a 3B2/400 running 5.3.1 this happens only when running 'ksh' and the bang command invokes ksh. If one escapes to 'sh', everything seems to be OK. This at least on 'ksh' from Aspen Technologies.