henry@zoo.toronto.edu (Henry Spencer) (10/13/90)
For the folks who've been getting bizarre exit-status values, like 1005, from newsrun... there are some indications that this may be an obscure shell problem arising from using a pipeline in an if condition. You might want to try deleting the following lines from newsrun: elif c7decode <$f 2>/dev/null | compress -d >$text 2>/dev/null then : okay This code gets used only for the 0.0001% of sites that use c7encoded transmission. -- "...the i860 is a wonderful source | Henry Spencer at U of Toronto Zoology of thesis topics." --Preston Briggs | henry@zoo.toronto.edu utzoo!henry
henry@zoo.toronto.edu (Henry Spencer) (10/14/90)
In article <1990Oct12.202800.19609@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >For the folks who've been getting bizarre exit-status values, like 1005, >from newsrun... there are some indications that this may be an obscure >shell problem arising from using a pipeline in an if condition. You >might want to try deleting the following lines from newsrun: > > elif c7decode <$f 2>/dev/null | compress -d >$text 2>/dev/null > then > : okay I am now fairly sure that this diagnosis is correct -- although it's hard to be absolutely certain since none of our systems appear to exhibit the problem -- and a note along these lines will appear in notebook/problems in the next patch. The underlying cause looks like a bug in shell handling of exit status: I think the shell is waiting for only one of the two processes in the pipeline, and is picking up a failure status from the other when it waits for relaynews to terminate. (I'm still not sure where a bizarre number like 1005 comes from, but the insides of both c7decode and compress are bizarre enough to explain almost anything... :-)) The type-tagging scheme that is in the works for more efficient input handling should eliminate the problem. -- "...the i860 is a wonderful source | Henry Spencer at U of Toronto Zoology of thesis topics." --Preston Briggs | henry@zoo.toronto.edu utzoo!henry