Date: Sun, 16 Sep 2012 21:20:14 GMT From: Jilles Tjoelker <jilles@stack.nl> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/171427: sh(1): Hitting ^Z doesn't suspend jobs like expected Message-ID: <201209162120.q8GLKEoC035120@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/171427; it has been noted by GNATS. From: Jilles Tjoelker <jilles@stack.nl> To: bug-followup@FreeBSD.org, yanegomi@gmail.com Cc: Subject: Re: bin/171427: sh(1): Hitting ^Z doesn't suspend jobs like expected Date: Sun, 16 Sep 2012 23:11:33 +0200 > [while : ; do netperf -cCjt TCP_STREAM -H 10.7.187.52 -l 10 -- -D; done > works strangely with ^C/^Z] For the case with ^C, I indeed deliberately fixed that for 9.0. For the case with ^Z, this is indeed a caveat that is complained about more frequently, and different shells handle it differently because POSIX leaves it vague. POSIX discusses suspending jobs (process groups), but a sequence or while loop is not a job. One workaround is to make it a job by placing parentheses around the loop. With most shells, this creates a new process group and job that can be suspended normally. An exception is ksh93 which attempts to execute the subshell in the same process; I do not like this but I think POSIX permits it (and in non-interactive or no-job-control mode it is fine to execute a subshell in that way). What sh does is return status 146 (128+SIGTSTP) and continue (so while netperf; do :; done will abort if ^Z'ed). What bash appears to do is break loops if something was ^Z'ed. What zsh appears to do is fork and continue the loop after the suspended process terminates. However, it gets $? wrong. Also, it needs a fair bit of code and changes to the shell environment after the suspension do not affect the parent. -- Jilles Tjoelker
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201209162120.q8GLKEoC035120>