Description of problem: Performing a wait on the pid of a co-process fails in the following circumstance: #!/bin/mksh ls -l |& pid=$! tee -a /tmp/out <&p wait $pid print $? The wait's return value is always 127. It does not matter whether the co-process exits with a successful value (e.g., "ls -l") or an unsuccessful value (e.g., "ls -l does-not-exist"); 127 is always returned. POSIX documentation on wait(1) (http://pubs.opengroup.org/onlinepubs/009695399/utilities/wait.html) states "If one or more pid operands are specified that represent unknown process IDs, wait shall treat them as if they were known process IDs that exited with exit status 127" and later on (in "Exit Status") indicates that 127 is returned only if "[t]he command identified by the last pid operand specified is unknown." --------------- Version-Release number of selected component (if applicable): mksh-55-1.fc26 How reproducible: Always Steps to Reproduce: Run sample code above using mksh -i Actual results: Return value of wait is always 127. Expected results: wait returns status of specified command This bug can't be reproduced when /etc/mksh OR ~/.mkshrc is missing, as the code setting PS1 from those files is required to trigger this bug. This seems to be minimized PS1 value to trigger the bug if you don't have mkshrc on your system: PS1='${|\\builtin typeset e=$?; \\builtin return $e; } '"\$ "
Thanks. The problem here was, apparently — I hope I’m right — that an interactive shell (still) did not remember (some) asynchronous PIDs. I’m not quite sure why this worked for simple async lists (“&”) in interactive mode, but the job reporting (the thing printing the “[1] + Done” messages) cleaned them up. I’ve committed a tentative fix which will be in R56: Index: src/bin/mksh/jobs.c diff -up src/bin/mksh/jobs.c:1.123 src/bin/mksh/jobs.c:1.124 --- src/bin/mksh/jobs.c:1.123 Tue Aug 8 14:29:23 2017 +++ src/bin/mksh/jobs.c Tue Aug 8 14:30:10 2017 @@ -1022,8 +1022,14 @@ j_notify(void) } for (j = job_list; j; j = tmp) { tmp = j->next; - if (j->flags & JF_REMOVE) - remove_job(j, "notify"); + if (j->flags & JF_REMOVE) { + if (j == async_job || (j->flags & JF_KNOWN)) { + j->flags = (j->flags & ~JF_REMOVE) | JF_ZOMBIE; + j->job = -1; + nzombie++; + } else + remove_job(j, "notify"); + } } shf_flush(shl_out); #ifndef MKSH_NOPROSPECTOFWORK
Thanks. I've checked the patch and it fixes the problem. No regression noted.
Thanks for confirming!
mksh-56-1.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-e2168704bd
mksh-56-1.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-5c09977559
mksh-56-1.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.
mksh-56-1.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.