Follow-up Comment #9, bug #68064 (group groff): [comment #7 comment #7:] > I somehow had it differently in memory, namely that its return > value is the return value of the executed comannd in a waitpid > fashion, which is not the case.
Even though it wasn't the value you expected (1), the value you got (0) is
still incorrect, so I agree with Branden that this should stay open until
someone can point to why it sometimes returns 0 for some people for some groff
versions. Why the result would be different when sent to stdout (as part of
the document) and stderr (via .tm) also baffles me.
One potentially notable difference for me: my 1.22.4 groff (which returns the
erroneous 0) is the one installed on the system, whereas my 1.23 groff (which
returns the expected 256) is called via test-groff.
[comment #8 comment #8:]
> Or maybe /bin/false doesn't exist on his system,
I started off using the /usr/bin/false path from the original report, but
quickly realized that's not a valid path on my system, so I changed to
/bin/false because that's where it lives for me. But it's a valid point that
this can vary by system. ("false" is also a shell builtin for at least bash,
though using a full path circumvents this.)
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?68064>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
