bin/171427: sh(1): Hitting ^Z doesn't suspend jobs like expected

[Jilles Tjoelker]

The following reply was made to PR bin/171427; it has been noted by GNATS.

From: Jilles Tjoelker <jilles at stack.nl>
To: bug-followup at FreeBSD.org, yanegomi at gmail.com
Cc:  
Subject: Re: bin/171427: sh(1): Hitting ^Z doesn&#39;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