View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
00019341003.1(2024)/Issue8Shell and Utilitiespublic2025-06-30 11:062025-06-30 11:06
Reportergeoffclare Assigned To 
PrioritynormalSeverityObjectionTypeClarification Requested
Status NewResolutionOpen 
NameGeoff Clare
OrganizationThe Open Group
User Reference
Sectionex
Page Number2868
Line Number95403
Interp Status---
Final Accepted Text
Summary0001934: ex's suspend command and job control
DescriptionThe description of the "suspend" command for ex says:
The suspension shall occur only if job control is enabled in the invoking shell (see the description of set -m).

This assumes ex (or vi) is invoked from a shell. It can also be invoked from other standard utilities, e.g. using the v command in more or the edit command in mailx (given a suitable EDITOR value). It could also, of course, be invoked directly from an application. Instead of specifying the behaviour in terms of how ex was invoked, the standard should specify what condition ex should check for.

The difference between job control enabled and disabled is that with job control enabled, the shell places the child process(es) for a job in a new process group. If ex is invoked directly by a (login) shell, it can tell whether the shell had job control enabled in two different ways:

1. It has a different process group than its parent.

2. Its process group ID is different than its session ID.

Choice 1 does the wrong thing if ex (or vi) is invoked from more or mailx (when more or mailx was invoked from a job control shell).

Choice 2 seems more in keeping with the spirit of what is intended, because the standard requires that typing the susp character in ex is equivalent to giving the "suspend" command, so ex should mimic what the general terminal interface would do for that character. However, this raises an additional problem regarding the sending of the SIGTSTP signal. The standard says "ex shall suspend itself as if it had received the SIGTSTP signal", which suggests that it should just send SIGTSTP to itself, but if it is to mimic what the GTI would do, it should send SIGTSTP to the process group, not just to itself. I used truss on Solaris 11.4 to see what /usr/xpg6/bin/ex does, and it called kill(0, SIGTSTP). I also checked nvi and vim on a Linux system with strace and they did the same.

The point of the condition on job control being disabled is so that ex does not suspend itself if nobody will notice. If the signal is actually being sent to the process group, then checking whether the session ID is different is exactly the right thing to do. If the session ID is the same, the session leader will be suspended (which is obviously a bad thing). If the session ID is different, then whatever process created the process group ex is in can be expected to notice the suspension of that group.
Desired ActionOn page 2841 line 94334 section ex (ASYNCHRONOUS EVENTS), change:
The action taken for all other signals is unspecified.
to:
The action taken for signals that stop the process shall be the default action. The action taken for all signals other than those that stop the process and those listed above is unspecified.

On page 2868 line 95402 section ex (suspend), change:
Allow control to return to the invoking process; ex shall suspend itself as if it had received the SIGTSTP signal. The suspension shall occur only if job control is enabled in the invoking shell (see the description of set -m).
to:
Suspend the process group to which ex belongs; ex shall send a SIGTSTP signal as if by a call to <tt>kill(0, SIGTSTP)</tt>, except that if the session ID of the session to which ex belongs is the same as its process group ID, no signal shall be sent.

After page 2902 line 96771 section ex (RATIONALE), add:
Suspend

The suspend command is intended to mimic the action of the General Terminal Interface (see [xref to XBD 11.1.9 Special Characters]) for the SUSP character, by sending a SIGTSTP signal to the process group. The condition on the session ID being different is in order not to suspend the session leader, which would likely lead to a situation that the user may have difficulty recovering from.
and move lines 96772-96774 (Set) to before line 96746 (Substitute).
TagsNo tags attached.

Activities

There are no notes attached to this issue.

Issue History

Date Modified Username Field Change
2025-06-30 11:06 geoffclare New Issue