xbd_chap03.html

IEEE 1003.1-2003, Single Unix Specification v3

<p>To continue a stopped job, the shell sends the SIGCONT signal to the process group of the job. In addition, if the job is being
continued in the foreground, the shell invokes <a href="../functions/tcsetpgrp.html"><i>tcsetpgrp</i>()</a> to place the job in the
foreground before sending SIGCONT. Otherwise, the shell leaves itself in the foreground and reads additional commands.</p>

<p>There is additional flexibility in the POSIX.1 job control facilities that allows deviations from the typical interface.
Clearing the TOSTOP terminal flag allows background jobs to perform <a href="../functions/write.html"><i>write</i>()</a> functions
without stopping. The same effect can be achieved on a per-process basis by having a process set the signal action for SIGTTOU to
SIG_IGN.</p>

<p>Note that the terms &quot;job&quot; and &quot;process group&quot; can be used interchangeably. A login session that is not using the job control
facilities can be thought of as a large collection of processes that are all in the same job (process group). Such a login session
may have a partial distinction between foreground and background processes; that is, the shell may choose to wait for some
processes before continuing to read new commands and may not wait for other processes. However, the terminal I/O driver will
consider all these processes to be in the foreground since they are all members of the same process group.</p>

<p>In addition to the basic job control operations already mentioned, a job control-cognizant shell needs to perform the following
actions.</p>

<p>When a foreground (not background) job stops, the shell must sample and remember the current terminal settings so that it can
restore them later when it continues the stopped job in the foreground (via the <a href=
"../functions/tcgetattr.html"><i>tcgetattr</i>()</a> and <a href="../functions/tcsetattr.html"><i>tcsetattr</i>()</a>
functions).</p>

<p>Because a shell itself can be spawned from a shell, it must take special action to ensure that subshells interact well with
their parent shells.</p>

<p>A subshell can be spawned to perform an interactive function (prompting the terminal for commands) or a non-interactive function
(reading commands from a file). When operating non-interactively, the job control shell will refrain from performing the job
control-specific actions described above. It will behave as a shell that does not support job control. For example, all jobs will
be left in the same process group as the shell, which itself remains in the process group established for it by its parent. This
allows the shell and its children to be treated as a single job by a parent shell, and they can be affected as a unit by terminal
keyboard signals.</p>

<p>An interactive subshell can be spawned from another job control-cognizant shell in either the foreground or background. (For
example, from the C&nbsp;Shell, the user can execute the command, CONVERSION ERROR (.Cm) csh &nbsp;&amp; .) Before the subshell
activates job control by calling <a href="../functions/setpgid.html"><i>setpgid</i>()</a> to place itself in its own process group
and <a href="../functions/tcsetpgrp.html"><i>tcsetpgrp</i>()</a> to place its new process group in the foreground, it needs to
ensure that it has already been placed in the foreground by its parent. (Otherwise, there could be multiple job control shells that
simultaneously attempt to control mediation of the terminal.) To determine this, the shell retrieves its own process group via <a
href="../functions/getpgrp.html"><i>getpgrp</i>()</a> and the process group of the current foreground job via <a href=
"../functions/tcgetpgrp.html"><i>tcgetpgrp</i>()</a>. If these are not equal, the shell sends SIGTTIN to its own process group,
causing itself to stop. When continued later by its parent, the shell repeats the process group check. When the process groups
finally match, the shell is in the foreground and it can proceed to take control. After this point, the shell ignores all the job
control stop signals so that it does not inadvertently stop itself.<br>
</p>

<p><i>Implementing Job Control Applications</i></p>

<p>Most applications do not need to be aware of job control signals and operations; the intuitively correct behavior happens by
default. However, sometimes an application can inadvertently interfere with normal job control processing, or an application may
choose to overtly effect job control in cooperation with normal shell procedures.</p>

<p>An application can inadvertently subvert job control processing by &quot;blindly&quot; altering the handling of signals. A common
application error is to learn how many signals the system supports and to ignore or catch them all. Such an application makes the
assumption that it does not know what this signal is, but knows the right handling action for it. The system may initialize the
handling of job control stop signals so that they are being ignored. This allows shells that do not support job control to inherit
and propagate these settings and hence to be immune to stop signals. A job control shell will set the handling to the default
action and propagate this, allowing processes to stop. In doing so, the job control shell is taking responsibility for restarting
the stopped applications. If an application wishes to catch the stop signals itself, it should first determine their inherited
handling states. If a stop signal is being ignored, the application should continue to ignore it. This is directly analogous to the
recommended handling of SIGINT described in the referenced UNIX Programmer's Manual.</p>

<p>If an application is reading the terminal and has disabled the interpretation of special characters (by clearing the ISIG flag),
the terminal I/O driver will not send SIGTSTP when the suspend character is typed. Such an application can simulate the effect of
the suspend character by recognizing it and sending SIGTSTP to its process group as the terminal driver would have done. Note that
the signal is sent to the process group, not just to the application itself; this ensures that other processes in the job also
stop. (Note also that other processes in the job could be children, siblings, or even ancestors.) Applications should not assume
that the suspend character is &lt;control&gt;-Z (or any particular value); they should retrieve the current setting at startup.<br>
</p>

<p><i>Implementing Job Control Systems</i></p>

<p>The intent in adding 4.2 BSD-style job control functionality was to adopt the necessary 4.2 BSD programmatic interface with only
minimal changes to resolve syntactic or semantic conflicts with System&nbsp;V or to close recognized security holes. The goal was
to maximize the ease of providing both conforming implementations and Conforming POSIX.1 Applications.</p>

<p>It is only useful for a process to be affected by job control signals if it is the descendant of a job control shell. Otherwise,
there will be nothing that continues the stopped process.</p>

<p>POSIX.1 does not specify how controlling terminal access is affected by a user logging out (that is, by a controlling process
terminating). 4.2 BSD uses the <i>vhangup</i>() function to prevent any access to the controlling terminal through file descriptors
opened prior to logout. System&nbsp;V does not prevent controlling terminal access through file descriptors opened prior to logout
(except for the case of the special file, <b>/dev/tty</b>). Some implementations choose to make processes immune from job control
after logout (that is, such processes are always treated as if in the foreground); other implementations continue to enforce
foreground/background checks after logout. Therefore, a Conforming POSIX.1 Application should not attempt to access the controlling
terminal after logout since such access is unreliable. If an implementation chooses to deny access to a controlling terminal after
its controlling process exits, POSIX.1 requires a certain type of behavior (see <a href="#tag_01_03_00_07">Controlling Terminal</a>
).</p>

<h5><a name="tag_01_03_00_29"></a>Kernel*</h5>

<p>See <a href="#tag_01_03_00_56">System Call*</a> .</p>

<h5><a name="tag_01_03_00_30"></a>Library Routine*</h5>

<p>See <a href="#tag_01_03_00_56">System Call*</a> .</p>

<h5><a name="tag_01_03_00_31"></a>Logical Device*</h5>

<p>Implementation-defined.</p>

<h5><a name="tag_01_03_00_32"></a>Map</h5>

<p>The definition of map is included to clarify the usage of mapped pages in the description of the behavior of process memory
locking.</p>

<h5><a name="tag_01_03_00_33"></a>Memory-Resident</h5>

<p>The term &quot;memory-resident&quot; is historically understood to mean that the so-called resident pages are actually present in the
physical memory of the computer system and are immune from swapping, paging, copy-on-write faults, and so on. This is the actual
intent of IEEE&nbsp;Std&nbsp;1003.1-2001 in the process memory locking section for implementations where this is logical. But for
some implementations-primarily mainframes-actually locking pages into primary storage is not advantageous to other system
objectives, such as maximizing throughput. For such implementations, memory locking is a &quot;hint&quot; to the implementation that the
application wishes to avoid situations that would cause long latencies in accessing memory. Furthermore, there are other
implementation-defined issues with minimizing memory access latencies that &quot;memory residency&quot; does not address-such as MMU reload
faults. The definition attempts to accommodate various implementations while allowing conforming applications to specify to the
implementation that they want or need the best memory access times that the implementation can provide.</p>

<h5><a name="tag_01_03_00_34"></a>Memory Object*</h5>

<p>The term &quot;memory object&quot; usually implies shared memory. If the object is the same as a filename in the file system name space
of the implementation, it is expected that the data written into the memory object be preserved on disk. A memory object may also
apply to a physical device on an implementation. In this case, writes to the memory object are sent to the controller for the
device and reads result in control registers being returned.</p>

<h5><a name="tag_01_03_00_35"></a>Mount Point*</h5>

<p>The directory on which a &quot;mounted file system&quot; is mounted. This term, like <i>mount</i>() and <i>umount</i>(), was not
included because it was implementation-defined.</p>

<h5><a name="tag_01_03_00_36"></a>Mounted File System*</h5>

<p>See <a href="#tag_01_03_00_20">File System</a> .</p>

<h5><a name="tag_01_03_00_37"></a>Name</h5>

<p>There are no explicit limits in IEEE&nbsp;Std&nbsp;1003.1-2001 on the sizes of names, words (see the definition of word in the
Base Definitions volume of IEEE&nbsp;Std&nbsp;1003.1-2001), lines, or other objects. However, other implicit limits do apply: shell
script lines produced by many of the standard utilities cannot exceed {LINE_MAX} and the sum of exported variables comes under the
{ARG_MAX} limit. Historical shells dynamically allocate memory for names and words and parse incoming lines a character at a time.
Lines cannot have an arbitrary {LINE_MAX} limit because of historical practice, such as makefiles, where <a href=
"../utilities/make.html"><i>make</i></a> removes the &lt;newline&gt;s associated with the commands for a target and presents the
shell with one very long line. The text on INPUT FILES in the Shell and Utilities volume of IEEE&nbsp;Std&nbsp;1003.1-2001, <a
href="../utilities/xcu_chap01.html#tag_01_11">Section 1.11, Utility Description Defaults</a> does allow a shell to run out of
memory, but it cannot have arbitrary programming limits.</p>

<h5><a name="tag_01_03_00_38"></a>Native Implementation*</h5>

<p>This refers to an implementation of POSIX.1 that interfaces directly to an operating system kernel; see also <i>hosted
implementation</i>. A similar concept is a native UNIX system, which would be a kernel derived from one of the original UNIX system
products.</p>

<h5><a name="tag_01_03_00_39"></a>Nice Value</h5>

<p>This definition is not intended to suggest that all processes in a system have priorities that are comparable. Scheduling policy
extensions, such as adding realtime priorities, make the notion of a single underlying priority for all scheduling policies
problematic. Some implementations may implement the features related to <a href="../utilities/nice.html"><i>nice</i></a> to affect
all processes on the system, others to affect just the general time-sharing activities implied by IEEE&nbsp;Std&nbsp;1003.1-2001,
and others may have no effect at all. Because of the use of &quot;implementation-defined&quot; in <a href=
"../utilities/nice.html"><i>nice</i></a> and <a href="../utilities/renice.html"><i>renice</i></a>, a wide range of implementation
strategies is possible.</p>

<h5><a name="tag_01_03_00_40"></a>Open File Description</h5>

<p>An &quot;open file description&quot;, as it is currently named, describes how a file is being accessed. What is currently called a
&quot;file descriptor&quot; is actually just an identifier or &quot;handle''; it does not actually describe anything.</p>

<p>The following alternate names were discussed:</p>

<ul>
<li>
<p>For &quot;open file description'':<br>
&quot;open instance&quot;, &quot;file access description&quot;, &quot;open file information&quot;, and &quot;file access information&quot;.</p>
</li>

<li>
<p>For &quot;file descriptor'':<br>
&quot;file handle&quot;, &quot;file number&quot; (cf., <a href="../functions/fileno.html"><i>fileno</i>()</a>). Some historical implementations use
the term &quot;file table entry&quot;.</p>
</li>