Hi Jacob, I think you were responding more to Karl here than to me, but your comments afford me the opportunity to point out a recent design feature of groff, and to further clarify my revised testing strategy.
At 2026-06-22T22:42:45-0500, Jacob Bachmeyer wrote:
[rearranging]
> To determine if the process was killed by a fatal signal, you must
> check the exit code.
>
> If you are concerned about a subprocess drawing a fatal signal, then
> you need to patch the driver process to detect and report when its
> child process dies by signal and have the test harness look for that
> error report. This would also improve error reporting to users.
Indeed, and as of groff 1.24, the groff(1) command, which constructs and
runs a pipeline, does exactly that.
NEWS:
* The groff command now encodes the fate of failing processes in the
pipeline it constructs and runs so that this information cannot be
confused with groff's own error conditions (such as a usage error,
which now produces an exit status of 2). See the section "Exit
status" of groff(1) for details.
groff(1):
Exit status
groff exits successfully (with status 0) if either of the options
-h or --help is specified, status 2 if the program cannot interpret
its command‐line arguments, and status 1 if it encounters an error
during operation. Otherwise, groff runs a pipeline to process its
input; if all commands within the pipeline exit successfully, groff
does likewise. If not, groff’s exit status encodes a summary of
problems encountered, setting bit 2 if a command exited with a
failure status, bit 3 if a command was terminated by a signal, and
bit 4 if a command could not be executed. (Thus, if all three
misfortunes befall one’s pipeline, groff exits with status 2^2 +
2^3 + 2^4 = 4+8+16 = 28.) To troubleshoot pipeline problems, re‐
run the groff command with the -V option and break the reported
pipeline down into separate stages, inspecting the exit status of,
and diagnostic messages emitted by, each command.
> You never really could rely on core files to appear---unprivileged
> ulimit -c cannot raise a hard limit and it was always possible for the
> hard limit on core files to be set to zero.
As it turned out, when revising the test scripts that checked for core
files produced by pic(1) or tbl(1), I didn't need to run groff(1) at
all. Because the preprocessors work as Unix filters, I merely gave them
some input, and checked that ending parts of that input, which the
preprocessors should not transform (the ".PE" and ".TE" tokens) appeared
in the commands' output. If the commands didn't crash with a fatal
signal, the token presence indicates a successful run.
Regards,
Branden
signature.asc
Description: PGP signature
