xbd_chap03.html

IEEE 1003.1-2003, Single Unix Specification v3

computer, rather than a <a href="../functions/write.html"><i>write</i>()</a> system call. An instance of user prompting might
appear in a dialog box, rather than with standard error. When the Shell and Utilities volume of IEEE&nbsp;Std&nbsp;1003.1-2001 uses
the term &quot;display&quot;, the method of outputting to the terminal is unspecified; many historical implementations use <i>termcap</i>
or <i>terminfo</i>, but this is not a requirement. The term &quot;write&quot; is used when the Shell and Utilities volume of
IEEE&nbsp;Std&nbsp;1003.1-2001 mandates that a file descriptor be used and that the output can be redirected. However, it is
assumed that when the writing is directly to the terminal (it has not been redirected elsewhere), there is no practical way for a
user or test suite to determine whether a file descriptor is being used. Therefore, the use of a file descriptor is mandated only
for the redirection case and the implementation is free to use any method when the output is not redirected. The verb <i>write</i>
is used almost exclusively, with the very few exceptions of those utilities where output redirection need not be supported: <a
href="../utilities/tabs.html"><i>tabs</i></a>, <a href="../utilities/talk.html"><i>talk</i></a>, <a href=
"../utilities/tput.html"><i>tput</i></a>, and <a href="../utilities/vi.html"><i>vi</i></a>.</p>

<h5><a name="tag_01_03_00_13"></a>Dot</h5>

<p>The symbolic name <i>dot</i> is carefully used in POSIX.1 to distinguish the working directory filename from a period or a
decimal point.</p>

<h5><a name="tag_01_03_00_14"></a>Dot-Dot</h5>

<p>Historical implementations permit the use of these filenames without their special meanings. Such use precludes any meaningful
use of these filenames by a Conforming POSIX.1 Application. Therefore, such use is considered an extension, the use of which makes
an implementation non-conforming; see also <a href="xbd_chap04.html#tag_01_04_11"><i>Pathname Resolution</i></a> .</p>

<h5><a name="tag_01_03_00_15"></a>Epoch</h5>

<p>Historically, the origin of UNIX system time was referred to as &quot;00:00:00 GMT, January 1, 1970&quot;. Greenwich Mean Time is
actually not a term acknowledged by the international standards community; therefore, this term, &quot;Epoch&quot;, is used to abbreviate
the reference to the actual standard, Coordinated Universal Time.</p>

<h5><a name="tag_01_03_00_16"></a>FIFO Special File</h5>

<p>See <a href="#tag_01_03_00_45">Pipe</a> .</p>

<h5><a name="tag_01_03_00_17"></a>File</h5>

<p>It is permissible for an implementation-defined file type to be non-readable or non-writable.</p>

<h5><a name="tag_01_03_00_18"></a>File Classes</h5>

<p>These classes correspond to the historical sets of permission bits. The classes are general to allow implementations flexibility
in expanding the access mechanism for more stringent security environments. Note that a process is in one and only one class, so
there is no ambiguity.</p>

<h5><a name="tag_01_03_00_19"></a>Filename</h5>

<p>At the present time, the primary responsibility for truncating filenames containing multi-byte characters must reside with the
application. Some industry groups involved in internationalization believe that in the future the responsibility must reside with
the kernel. For the moment, a clearer understanding of the implications of making the kernel responsible for truncation of
multi-byte filenames is needed.</p>

<p>Character-level truncation was not adopted because there is no support in POSIX.1 that advises how the kernel distinguishes
between single and multi-byte characters. Until that time, it must be incumbent upon application writers to determine where
multi-byte characters must be truncated.</p>

<h5><a name="tag_01_03_00_20"></a>File System</h5>

<p>Historically, the meaning of this term has been overloaded with two meanings: that of the complete file hierarchy, and that of a
mountable subset of that hierarchy; that is, a mounted file system. POSIX.1 uses the term &quot;file system&quot; in the second sense,
except that it is limited to the scope of a process (and a process' root directory). This usage also clarifies the domain in which
a file serial number is unique.</p>

<h5><a name="tag_01_03_00_21"></a>Graphic Character</h5>

<p>This definition is made available for those definitions (in particular, <i>TZ )</i> which must exclude control characters.</p>

<h5><a name="tag_01_03_00_22"></a>Group Database</h5>

<p>See <a href="#tag_01_03_00_63">User Database</a> .</p>

<h5><a name="tag_01_03_00_23"></a>Group File*</h5>

<p>Implementation-defined; see <a href="#tag_01_03_00_63">User Database</a> .</p>

<h5><a name="tag_01_03_00_24"></a>Historical Implementations*</h5>

<p>This refers to previously existing implementations of programming interfaces and operating systems that are related to the
interface specified by POSIX.1.</p>

<h5><a name="tag_01_03_00_25"></a>Hosted Implementation*</h5>

<p>This refers to a POSIX.1 implementation that is accomplished through interfaces from the POSIX.1 services to some alternate form
of operating system kernel services. Note that the line between a hosted implementation and a native implementation is blurred,
since most implementations will provide some services directly from the kernel and others through some indirect path. (For example,
<a href="../functions/fopen.html"><i>fopen</i>()</a> might use <a href="../functions/open.html"><i>open</i>()</a>; or <a href=
"../functions/mkfifo.html"><i>mkfifo</i>()</a> might use <a href="../functions/mknod.html"><i>mknod</i>()</a>.) There is no
necessary relationship between the type of implementation and its correctness, performance, and/or reliability.</p>

<h5><a name="tag_01_03_00_26"></a>Implementation*</h5>

<p>This term is generally used instead of its synonym, &quot;system&quot;, to emphasize the consequences of decisions to be made by system
implementors. Perhaps if no options or extensions to POSIX.1 were allowed, this usage would not have occurred.</p>

<p>The term &quot;specific implementation&quot; is sometimes used as a synonym for &quot;implementation&quot;. This should not be interpreted too
narrowly; both terms can represent a relatively broad group of systems. For example, a hardware vendor could market a very wide
selection of systems that all used the same instruction set, with some systems desktop models and others large multi-user
minicomputers. This wide range would probably share a common POSIX.1 operating system, allowing an application compiled for one to
be used on any of the others; this is a [ <i>specific</i>] <i>implementation</i>. However, such a wide range of machines probably
has some differences between the models. Some may have different clock rates, different file systems, different resource limits,
different network connections, and so on, depending on their sizes or intended usages. Even on two identical machines, the system
administrators may configure them differently. Each of these different systems is known by the term &quot;a specific instance of a
specific implementation&quot;. This term is only used in the portions of POSIX.1 dealing with runtime queries: <a href=
"../functions/sysconf.html"><i>sysconf</i>()</a> and <a href="../functions/pathconf.html"><i>pathconf</i>()</a>.</p>

<h5><a name="tag_01_03_00_27"></a>Incomplete Pathname*</h5>

<p>Absolute pathname has been adequately defined.</p>

<h5><a name="tag_01_03_00_28"></a>Job Control</h5>

<p>In order to understand the job control facilities in POSIX.1 it is useful to understand how they are used by a job
control-cognizant shell to create the user interface effect of job control.</p>

<p>While the job control facilities supplied by POSIX.1 can, in theory, support different types of interactive job control
interfaces supplied by different types of shells, there was historically one particular interface that was most common when the
standard was originally developed (provided by BSD C&nbsp;Shell). This discussion describes that interface as a means of
illustrating how the POSIX.1 job control facilities can be used.</p>

<p>Job control allows users to selectively stop (suspend) the execution of processes and continue (resume) their execution at a
later point. The user typically employs this facility via the interactive interface jointly supplied by the terminal I/O driver and
a command interpreter (shell).</p>

<p>The user can launch jobs (command pipelines) in either the foreground or background. When launched in the foreground, the shell
waits for the job to complete before prompting for additional commands. When launched in the background, the shell does not wait,
but immediately prompts for new commands.</p>

<p>If the user launches a job in the foreground and subsequently regrets this, the user can type the suspend character (typically
set to &lt;control&gt;-Z), which causes the foreground job to stop and the shell to begin prompting for new commands. The stopped
job can be continued by the user (via special shell commands) either as a foreground job or as a background job. Background jobs
can also be moved into the foreground via shell commands.</p>

<p>If a background job attempts to access the login terminal (controlling terminal), it is stopped by the terminal driver and the
shell is notified, which, in turn, notifies the user. (Terminal access includes <a href="../functions/read.html"><i>read</i>()</a>
and certain terminal control functions, and conditionally includes <a href="../functions/write.html"><i>write</i>()</a>.) The user
can continue the stopped job in the foreground, thus allowing the terminal access to succeed in an orderly fashion. After the
terminal access succeeds, the user can optionally move the job into the background via the suspend character and shell
commands.<br>
</p>

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

<p>The interactive interface described previously can be accomplished using the POSIX.1 job control facilities in the following
way.</p>

<p>The key feature necessary to provide job control is a way to group processes into jobs. This grouping is necessary in order to
direct signals to a single job and also to identify which job is in the foreground. (There is at most one job that is in the
foreground on any controlling terminal at a time.)</p>

<p>The concept of process groups is used to provide this grouping. The shell places each job in a separate process group via the <a
href="../functions/setpgid.html"><i>setpgid</i>()</a> function. To do this, the <a href=
"../functions/setpgid.html"><i>setpgid</i>()</a> function is invoked by the shell for each process in the job. It is actually
useful to invoke <a href="../functions/setpgid.html"><i>setpgid</i>()</a> twice for each process: once in the child process, after
calling <a href="../functions/fork.html"><i>fork</i>()</a> to create the process, but before calling one of the <i>exec</i> family
of functions to begin execution of the program, and once in the parent shell process, after calling <a href=
"../functions/fork.html"><i>fork</i>()</a> to create the child. The redundant invocation avoids a race condition by ensuring that
the child process is placed into the new process group before either the parent or the child relies on this being the case. The
process group ID for the job is selected by the shell to be equal to the process ID of one of the processes in the job. Some shells
choose to make one process in the job be the parent of the other processes in the job (if any). Other shells (for example, the
C&nbsp;Shell) choose to make themselves the parent of all processes in the pipeline (job). In order to support this latter case,
the <a href="../functions/setpgid.html"><i>setpgid</i>()</a> function accepts a process group ID parameter since the correct
process group ID cannot be inherited from the shell. The shell itself is considered to be a job and is the sole process in its own
process group.</p>

<p>The shell also controls which job is currently in the foreground. A foreground and background job differ in two ways: the shell
waits for a foreground command to complete (or stop) before continuing to read new commands, and the terminal I/O driver inhibits
terminal access by background jobs (causing the processes to stop). Thus, the shell must work cooperatively with the terminal I/O
driver and have a common understanding of which job is currently in the foreground. It is the user who decides which command should
be currently in the foreground, and the user informs the shell via shell commands. The shell, in turn, informs the terminal I/O
driver via the <a href="../functions/tcsetpgrp.html"><i>tcsetpgrp</i>()</a> function. This indicates to the terminal I/O driver the
process group ID of the foreground process group (job). When the current foreground job either stops or terminates, the shell
places itself in the foreground via <a href="../functions/tcsetpgrp.html"><i>tcsetpgrp</i>()</a> before prompting for additional
commands. Note that when a job is created the new process group begins as a background process group. It requires an explicit act
of the shell via <a href="../functions/tcsetpgrp.html"><i>tcsetpgrp</i>()</a> to move a process group (job) into the
foreground.</p>

<p>When a process in a job stops or terminates, its parent (for example, the shell) receives synchronous notification by calling
the <a href="../functions/waitpid.html"><i>waitpid</i>()</a> function with the WUNTRACED flag set. Asynchronous notification is
also provided when the parent establishes a signal handler for SIGCHLD and does not specify the SA_NOCLDSTOP flag. Usually all
processes in a job stop as a unit since the terminal I/O driver always sends job control stop signals to all processes in the
process group.</p>