The exit status of command terminated with a signal in the pipeline seems be wrong

[ko1nksm]

The seq command seems to terminate with 256+signum (unlike 128+signum in other shells) as expected, but the shell does not seem to get the values right. Perhaps it has something to do with the exit status value obtained from the subshell, but I don't know what is right.

ksh93u+m/1.1.0-alpha+8f84f4b2

$ ksh -c 'set -o pipefail; (seq 1000000; xs=$?; echo $xs >&2; exit $xs) | head > /dev/null; echo $?'
269
13

$ ksh -c '(exit 255); echo $?; (exit 256); echo $?; (exit 257); echo $?'
255
0
1

$ ksh -c 'set -o pipefail; (exit 255)|:; echo $?; (exit 256)|:; echo $?; (exit 257)|:; echo $?'
255
0
1

ksh93u+

$ ksh -c 'set -o pipefail; (seq 1000000; xs=$?; echo $xs >&2; exit $xs) | head > /dev/null; echo $?'
269
141

$ ksh -c '(exit 255); echo $?; (exit 256); echo $?; (exit 257); echo $?'
255
0
257

$ ksh -c 'set -o pipefail; (exit 255)|:; echo $?; (exit 256)|:; echo $?; (exit 257)|:; echo $?'
255
0
129

[McDutchie]

ksh 93u+m works as expected here. The 93u+ behaviour is buggy and has been fixed.

When a subshell exits, the exit status ($?) is trimmed to its least significant 8 bits. For a separate process (such as a real subshell) this is enforced by the kernel. So a virtual subshell should act the same, because its operation should be indistinguishable from a real subshell. See b90b8cd.

The exception is if a subshell, or the last command it ran, was terminated by a signal. The signal is then reissued to the parent environment and you get an exit status > 256. But that is not the case in your examples, because your subshells all exit normally with the exit command.

I hope this clarifies.

[ko1nksm]

Thanks for explaining. I have made some misunderstandings and I guess I did not explain the issue correctly. The reproduction code I provided was more complex than necessary and misleading. What I should have explained is this.

$ set -o pipefail
$ seq 1000000 | head > /dev/null
$ echo $?
13

The seq command terminated by SIGPIPE, but the exit status is 13. The reason I think this is problematic is that we don't know that the seq command terminated by a signal (and I wish ksh had PIPESTATUS). And POSIX specifies an exit status of 128 or higher when exiting on a signal.

From my investigation, it appears that this behavior was changed in ksh93u+, although I am not sure if this was intentional or not. On ksh93s+ (debian 6.0) and ksh93t+ (OpenIndiana 2013.08) it works as follows:

$ set -o pipefail
$ seq 1000000 | head > /dev/null
$ echo $?
269

[McDutchie]

Indeed, that is broken. I apologise for closing #742 prematurely.

The following patch should fix it:

diff --git a/src/cmd/ksh93/sh/jobs.c b/src/cmd/ksh93/sh/jobs.c
index 676de21fd..8b038470c 100644
--- a/src/cmd/ksh93/sh/jobs.c
+++ b/src/cmd/ksh93/sh/jobs.c
@@ -1640,7 +1640,11 @@ static struct process *job_unpost(struct process *pwtop,int notify)
 	for(pw=pwtop; pw; pw=pw->p_nxtproc)
 	{
 		if(pw && pw->p_exitval)
+		{
 			*pw->p_exitval = pw->p_exit;
+			if(pw->p_flag&P_SIGNALLED)
+				*pw->p_exitval |= SH_EXITSIG;
+		}	
 		/* save the exit status for background jobs */
 		if((pw->p_flag&P_EXITSAVE) ||  pw->p_pid==sh.spid)
 		{

[McDutchie]

I'm testing my stash of historic ksh versions compiled on Debian arm64 from the ksh93-history repo. Version 93u 2011-03-10 and before do not have the bug; the bug is present as of 93u+ 2011-04-15, which (by the looks of it) rewrote the code for the pipefail option. They just seem to have forgotten about setting the 9th bit (a.k.a. SH_EXITSIG) in the exit status if a process got signalled.

[ko1nksm]

Thank you for the fix!

I apologise for closing #742 prematurely.

Don't worry about it. I often also wonder if I should move Issues to Discussions.

I'm testing my stash of historic ksh versions compiled on Debian arm64 from the ksh93-history repo.

Oh, I was not aware of the ksh93-history repository. To test with ksh93t+, I had an old OpenIndiana installation and registration with IBM Cloud 😅. Next time I will be able to provide more info.