Reorganizing signal handling tests
Signal handling requirements (excerpted):
XCU 1.4
ASYNCHRONOUS EVENTS Default Behavior: When this section is listed as "Default.", or it refers to "the standard action for all other signals; see Utility Description Defaults " it means that the action taken as a result of the signal shall be one of the following: * The action shall be that inherited from the parent according to the rules of inheritance of signal actions defined in the System Interfaces volume of POSIX.1-2017. * When no action has been taken to change the default, the default action shall be that specified by the System Interfaces volume of POSIX.1-2017. * The result of the utility's execution is as if default actions had been taken. A utility is permitted to catch a signal, perform some additional processing (such as deleting temporary files), restore the default signal action (or action inherited from the parent process), and resignal itself.
XCU 2.11
If job control is disabled when the shell executes an asynchronous list, the commands in the list shall inherit from the shell a signal action of ignored (SIG_IGN) for the SIGINT and SIGQUIT signals. In all other cases, commands executed by the shell shall inherit the same signal actions as those inherited by the shell from its parent unless a signal action is modified by the trap special built-in When a signal for which a trap has been set is received while the shell is waiting for the completion of a utility executing a foreground command, the trap associated with that signal shall not be executed until after the foreground command has completed. When the shell is waiting, by means of the wait utility, for asynchronous commands to complete, the reception of a signal for which a trap has been set shall cause the wait utility to return immediately with an exit status >128, immediately after which the trap associated with that signal shall be taken. If multiple signals are pending for the shell for which there are associated trap actions, the order of execution of trap actions is unspecified.
XCU 2.12
If the utility is a shell script, traps caught by the shell shall be set to the default values and traps ignored by the shell shall be set to be ignored by the utility; if the utility is not a shell script, the trap actions (default or ignore) shall be mapped into the appropriate signal handling actions for the utility A subshell environment shall be created as a duplicate of the shell environment, except that signal traps that are not being ignored shall be set to the default action.
XCU The trap built-in
Signals that were ignored on entry to a non-interactive shell cannot be trapped or reset, although no error need be reported when attempting to do so. An interactive shell may reset or catch signals ignored on entry. Traps shall remain in place for a given shell until explicitly changed with another trap command.
XCU The sh command, asynchronous events
The sh utility shall take the standard action for all signals (see Utility Description Defaults) with the following exceptions. If the shell is interactive, SIGINT signals received during command line editing shall be handled as described in the EXTENDED DESCRIPTION, and SIGINT signals received at other times shall be caught but no action performed. If the shell is interactive: * SIGQUIT and SIGTERM signals shall be ignored. * If the -m option is in effect, SIGTTIN, SIGTTOU, and SIGTSTP signals shall be ignored. * If the -m option is not in effect, it is unspecified whether SIGTTIN, SIGTTOU, and SIGTSTP signals are ignored, set to the default action, or caught. If they are caught, the shell shall, in the signal-catching function, set the signal to the default action and raise the signal (after taking any appropriate steps, such as restoring terminal settings). The standard actions, and the actions described above for interactive shells, can be overridden by use of the trap special built-in utility (see trap and Signals and Error Handling).
XCU The sh command, Command Line Editing (vi-mode)
If sh receives a SIGINT signal in command mode (whether generated by typing the interrupt character or by other means), it shall terminate command line editing on the current command line, reissue the prompt on the next line of the terminal, and reset the command history (see fc) so that the most recently executed command is the previous command (that is, the command that was being edited when it was interrupted is not re-entered into the history).
XCU The sh coomand, vi Line Editing Insert Model
If sh receives a SIGINT signal in insert mode (whether generated by typing the interrupt character or by other means), it shall terminate command line editing with the same effects as described for interrupting command mode; see Command Line Editing (vi-mode).
Summary:
Test parameter dimensions:
Expected result variation:
Combinations of "Signal sent to", "in context" and "Signal sent from":
- # shell, main shell environment, receiving process
- kill -s $SIG $$
- :
- # shell, main shell environment, other process
- "$TESTEE" -c 'kill -s $SIG $PPID'
- # shell, subshell, receiving process
- (
- kill -s $SIG $(exec "$TESTEE" -c 'echo $PPID') # note 1
- :
- :
- )
- # shell, subshell, other process
- (
- "$TESTEE" -c 'kill -s $SIG $PPID'
- :
- )
- # shell, command subshell, receiving process
- echo $(
- kill -s $SIG $(exec "$TESTEE" -c 'echo $PPID') # note 1
- :
- )
- # shell, command subshell, other process
- echo $(
- "$TESTEE" -c 'kill -s $SIG $PPID'
- :
- )
- # shell, asynchronous list, receiving process
- {
- kill -s $SIG $(exec "$TESTEE" -c 'echo $PPID') # note 1
- :
- } & wait $!
- # shell, asynchronous list, other process
- {
- "$TESTEE" -c 'kill -s $SIG $PPID'
- :
- } & wait $!
- # external command (child process), main shell environment, receiving process
- "$TESTEE" <<\END
- kill -s $SIG $$
- :
- END
- # external command (child process), main shell environment, other process
- "$TESTEE" <<\END
- "$TESTEE" -c 'kill -s $SIG $PPID'
- :
- END
- # external command (child process), subshell, receiving process
- (
- "$TESTEE" <<\END
- kill -s $SIG $$
- :
- END
- :
- )
- # external command (child process), subshell, other process
- (
- "$TESTEE" <<\END
- "$TESTEE" -c 'kill -s $SIG $PPID'
- :
- END
- :
- )
- # external command (child process), command substitution, receiving process
- echo $(
- "$TESTEE" <<\END
- kill -s $SIG $$
- :
- END
- :
- )
- # external command (child process), command substitution, other process
- echo $(
- "$TESTEE" <<\END
- "$TESTEE" -c 'kill -s $SIG $PPID'
- :
- END
- :
- )
- # external command (child process), asynchronous list, receiving process
- {
- "$TESTEE" <<\END
- kill -s $SIG $$
- :
- END
- :
- } & wait $!
- # external command (child process), asynchronous list, other process
- {
- "$TESTEE" <<\END
- "$TESTEE" -c 'kill -s $SIG $PPID'
- :
- END
- :
- } & wait $!
Note 1: POSIX does not require a subshell environment to have a process ID that is distinct from the main shell's process ID. The trick to obtain the subshell's process ID is yash-specific.
Implemented in r4118
signal-y{1..9}.tst にあるテストを再構成する。組合せ数が多いので直交表で間引くべきか