Ticket #40851

Reorganizing signal handling tests

Open Date: 2020-10-09 23:24 Last Update: 2020-10-31 22:52

Reporter:
Owner:
Type:
Status:
Closed
Component:
MileStone:
(None)
Priority:
5 - Medium
Severity:
3
Resolution:
Fixed
File:
None
Vote
Score: 0
No votes
0.0% (0/0)
0.0% (0/0)

Details

signal-y{1..9}.tst にあるテストを再構成する。組合せ数が多いので直交表で間引くべきか

Ticket History (3/5 Histories)

2020-10-09 23:24 Updated by: magicant
  • New Ticket "Reorganizing signal handling tests" created
2020-10-10 18:28 Updated by: magicant
Comment

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).

2020-10-10 19:23 Updated by: magicant
Comment

Summary:

  • If not job-controlling, an asynchronous list must ignore SIGINT and SIGQUIT.
  • If interactive, the shell may reset inherited actions.
  • If interactive, the shell must ignore SIGQUIT and SIGTERM.
  • If interactive, the shell must catch SIGINT.
  • If (interactive and) job-controlling, the shell must ignore SIGTTIN, SIGTTOU and SIGTSTP.
  • If (interactive and) not job-controlling, the shell may ignore SIGTTIN, SIGTTOU and SIGTSTP.
  • If not interactive, inherited ignored signals cannot be reset.

Test parameter dimensions:

  • Signal: ALRM, (CHLD), CONT, URG, HUP, INT, QUIT, TERM, TSTP, TTIN, TTOU, PIPE, (WINCH), (RTMIN), (RTMAX)
  • Signal sent to: shell vs. external command (child process) vs. external command (exec)
  • In context: main shell environment vs. subshell vs. command substitution vs. asynchronous list
  • Signal sent from: receiving process vs. other process
  • Interactive vs. non-interactive
  • Job-controlling vs. non-job-controlling
  • Action inherited from parent: default vs. ignore
  • Trap in main context: unchanged vs. cleared vs. ignore vs. command
  • Trap in new context: unchanged vs. cleared vs. ignore vs. command

Expected result variation:

  • Ignored vs. terminated vs. trapped vs. stopped vs. continued
(Edited, 2020-10-11 22:52 Updated by: magicant)
2020-10-11 01:56 Updated by: magicant
Comment

Combinations of "Signal sent to", "in context" and "Signal sent from":

  1. # shell, main shell environment, receiving process
  2. kill -s $SIG $$
  3. :
  4. # shell, main shell environment, other process
  5. "$TESTEE" -c 'kill -s $SIG $PPID'
  6. # shell, subshell, receiving process
  7. (
  8. kill -s $SIG $(exec "$TESTEE" -c 'echo $PPID') # note 1
  9. :
  10. :
  11. )
  12. # shell, subshell, other process
  13. (
  14. "$TESTEE" -c 'kill -s $SIG $PPID'
  15. :
  16. )
  17. # shell, command subshell, receiving process
  18. echo $(
  19. kill -s $SIG $(exec "$TESTEE" -c 'echo $PPID') # note 1
  20. :
  21. )
  22. # shell, command subshell, other process
  23. echo $(
  24. "$TESTEE" -c 'kill -s $SIG $PPID'
  25. :
  26. )
  27. # shell, asynchronous list, receiving process
  28. {
  29. kill -s $SIG $(exec "$TESTEE" -c 'echo $PPID') # note 1
  30. :
  31. } & wait $!
  32. # shell, asynchronous list, other process
  33. {
  34. "$TESTEE" -c 'kill -s $SIG $PPID'
  35. :
  36. } & wait $!
  37. # external command (child process), main shell environment, receiving process
  38. "$TESTEE" <<\END
  39. kill -s $SIG $$
  40. :
  41. END
  42. # external command (child process), main shell environment, other process
  43. "$TESTEE" <<\END
  44. "$TESTEE" -c 'kill -s $SIG $PPID'
  45. :
  46. END
  47. # external command (child process), subshell, receiving process
  48. (
  49. "$TESTEE" <<\END
  50. kill -s $SIG $$
  51. :
  52. END
  53. :
  54. )
  55. # external command (child process), subshell, other process
  56. (
  57. "$TESTEE" <<\END
  58. "$TESTEE" -c 'kill -s $SIG $PPID'
  59. :
  60. END
  61. :
  62. )
  63. # external command (child process), command substitution, receiving process
  64. echo $(
  65. "$TESTEE" <<\END
  66. kill -s $SIG $$
  67. :
  68. END
  69. :
  70. )
  71. # external command (child process), command substitution, other process
  72. echo $(
  73. "$TESTEE" <<\END
  74. "$TESTEE" -c 'kill -s $SIG $PPID'
  75. :
  76. END
  77. :
  78. )
  79. # external command (child process), asynchronous list, receiving process
  80. {
  81. "$TESTEE" <<\END
  82. kill -s $SIG $$
  83. :
  84. END
  85. :
  86. } & wait $!
  87. # external command (child process), asynchronous list, other process
  88. {
  89. "$TESTEE" <<\END
  90. "$TESTEE" -c 'kill -s $SIG $PPID'
  91. :
  92. END
  93. :
  94. } & 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.

(Edited, 2020-10-11 18:00 Updated by: magicant)
2020-10-31 22:52 Updated by: magicant
  • Resolution Update from None to Fixed
  • Status Update from Open to Closed
Comment

Implemented in r4118

Attachment File List

No attachments

Edit

You are not logged in. I you are not logged in, your comment will be treated as an anonymous post. » Login