On 14/08/2025 06:01, Collin Funk wrote:
Collin Funk <collin.fu...@gmail.com> writes:
I'll have a look at implementing this behavior. But figured it was worth
sending on bug-coreutils for tracking like the rest of the missing POSIX
2024 features.
I have attached a proposed patch.
I followed the POSIX recommendation of using the exit status 0 - 124 for
the number of cycles and 125 for program errors (e.g. closing standard
output).
-w seems a bit arbitrary to standardize since I only see it in OpenBSD:
https://manned.org/man/openbsd-7.7/tsort
Also exit status is a weird interface to propagate numbers,
with various limitations and overlaps.
But it doesn't cost much to implement, so fair enough.
It's good to limit to < 125 anyway.
But I have hidden the 125 exit status behind POSIXLY_CORRECT. To avoid
breaking something like this:
tsort input-file
if test $? -eq 1; then
echo do something
fi
I don't think that edge case is worth worrying about,
given tsort is less often used, and that's not a normal way to check errors.
So we could just always exit >= 125 on error, and
it would suffice to mention this in NEWS under "Change in behavior".
But I'm inclined to only do the exit status adjustments if -w was specified.
and just document the exit status range in the info docs for -w,
and no further changes to NEWS.
If we can agree on that behavior, I'll probably move tests/misc/tsort.pl
to a separate tsort directory in tests. And then add a shell script to
test the behavior of POSIXLY_CORRECT on the exit status using /dev/full.
In general it's better to err on a separate dir per util.
thanks!
Padraig
