📄 xbd_chap11.html
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head><meta name="generator" content="HTML Tidy, see www.w3.org"><meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"><link type="text/css" rel="stylesheet" href="style.css"><!-- Generated by The Open Group's rhtm tool v1.2.1 --><!-- Copyright (c) 2001-2003 The Open Group, All Rights Reserved --><title>Rationale</title></head><body><basefont size="3"> <center><font size="2">The Open Group Base Specifications Issue 6<br>IEEE Std 1003.1, 2003 Edition<br>Copyright © 2001-2003 The IEEE and The Open Group</font></center><hr size="2" noshade><h3><a name="tag_01_11"></a>General Terminal Interface</h3><p>If the implementation does not support this interface on any device types, it should behave as if it were being used on a devicethat is not a terminal device (in most cases <i>errno</i> will be set to [ENOTTY] on return from functions defined by thisinterface). This is based on the fact that many applications are written to run both interactively and in some non-interactivemode, and they adapt themselves at runtime. Requiring that they all be modified to test an environment variable to determinewhether they should try to adapt is unnecessary. On a system that provides no general terminal interface, providing all the entrypoints as stubs that return [ENOTTY] (or an equivalent, as appropriate) has the same effect and requires no changes to theapplication.</p><p>Although the needs of both interface implementors and application developers were addressed throughoutIEEE Std 1003.1-2001, this section pays more attention to the needs of the latter. This is because, while many aspects ofthe programming interface can be hidden from the user by the application developer, the terminal interface is usually a large partof the user interface. Although to some extent the application developer can build missing features or work around inappropriateones, the difficulties of doing that are greater in the terminal interface than elsewhere. For example, efficiency prohibits theaverage program from interpreting every character passing through it in order to simulate character erase, line kill, and so on.These functions should usually be done by the operating system, possibly at the interrupt level.</p><p>The <i>tc*</i>() functions were introduced as a way of avoiding the problems inherent in thetraditional <a href="../functions/ioctl.html"><i>ioctl</i>()</a> function and in variants of it that were proposed. For example, <ahref="../functions/tcsetattr.html"><i>tcsetattr</i>()</a> is specified in place of the use of the TCSETA <a href="../functions/ioctl.html"><i>ioctl</i>()</a> command function. This allows specification of all the arguments in a mannerconsistent with the ISO C standard unlike the varying third argument of <a href="../functions/ioctl.html"><i>ioctl</i>()</a>,which is sometimes a pointer (to any of many different types) and sometimes an <b>int</b>.</p><p>The advantages of this new method include:</p><ul><li><p>It allows strict type checking.</p></li><li><p>The direction of transfer of control data is explicit.</p></li><li><p>Portable capabilities are clearly identified.</p></li><li><p>The need for a general interface routine is avoided.</p></li><li><p>Size of the argument is well-defined (there is only one type).</p></li></ul><p>The disadvantages include:</p><ul><li><p>No historical implementation used the new method.</p></li><li><p>There are many small routines instead of one general-purpose one.</p></li><li><p>The historical parallel with <a href="../functions/fcntl.html"><i>fcntl</i>()</a> is broken.</p></li></ul><p>The issue of modem control was excluded from IEEE Std 1003.1-2001 on the grounds that:</p><ul><li><p>It was concerned with setting and control of hardware timers.</p></li><li><p>The appropriate timers and settings vary widely internationally.</p></li><li><p>Feedback from European computer manufacturers indicated that this facility was not consistent with European needs and thatspecification of such a facility was not a requirement for portability.</p></li></ul><h4><a name="tag_01_11_01"></a>Interface Characteristics</h4><h5><a name="tag_01_11_01_01"></a>Opening a Terminal Device File</h5><p>There is no additional rationale provided for this section.</p><h5><a name="tag_01_11_01_02"></a>Process Groups</h5><p>There is a potential race when the members of the foreground process group on a terminal leave that process group, either byexit or by changing process groups. After the last process exits the process group, but before the foreground process group ID ofthe terminal is changed (usually by a job control shell), it would be possible for a new process to be created with its process IDequal to the terminal's foreground process group ID. That process might then become the process group leader and accidentally beplaced into the foreground on a terminal that was not necessarily its controlling terminal. As a result of this problem, thecontrolling terminal is defined to not have a foreground process group during this time.</p><p>The cases where a controlling terminal has no foreground process group occur when all processes in the foreground process groupeither terminate and are waited for or join other process groups via <a href="../functions/setpgid.html"><i>setpgid</i>()</a> or <ahref="../functions/setsid.html"><i>setsid</i>()</a>. If the process group leader terminates, this is the first case described; ifit leaves the process group via <a href="../functions/setpgid.html"><i>setpgid</i>()</a>, this is the second case described (aprocess group leader cannot successfully call <a href="../functions/setsid.html"><i>setsid</i>()</a>). When one of those casescauses a controlling terminal to have no foreground process group, it has two visible effects on applications. The first is thevalue returned by <a href="../functions/tcgetpgrp.html"><i>tcgetpgrp</i>()</a>. The second (which occurs only in the case where theprocess group leader terminates) is the sending of signals in response to special input characters. The intent ofIEEE Std 1003.1-2001 is that no process group be wrongly identified as the foreground process group by <a href="../functions/tcgetpgrp.html"><i>tcgetpgrp</i>()</a> or unintentionally receive signals because of placement into theforeground.</p><p>In 4.3 BSD, the old process group ID continues to be used to identify the foreground process group and is returned by thefunction equivalent to <a href="../functions/tcgetpgrp.html"><i>tcgetpgrp</i>()</a>. In that implementation it is possible for anewly created process to be assigned the same value as a process ID and then form a new process group with the same value as aprocess group ID. The result is that the new process group would receive signals from this terminal for no apparent reason, andIEEE Std 1003.1-2001 precludes this by forbidding a process group from entering the foreground in this way. It would bemore direct to place part of the requirement made by the last sentence under <a href="../functions/fork.html"><i>fork</i>()</a>,but there is no convenient way for that section to refer to the value that <a href="../functions/tcgetpgrp.html"><i>tcgetpgrp</i>()</a> returns, since in this case there is no process group and thus no processgroup ID.</p><p>One possibility for a conforming implementation is to behave similarly to 4.3 BSD, but to prevent this reuse of the ID, probablyin the implementation of <a href="../functions/fork.html"><i>fork</i>()</a>, as long as it is in use by the terminal.</p><p>Another possibility is to recognize when the last process stops using the terminal's foreground process group ID, which is whenthe process group lifetime ends, and to change the terminal's foreground process group ID to a reserved value that is never used asa process ID or process group ID. (See the definition of <i>process group lifetime</i> in the definitions section.) The process IDcan then be reserved until the terminal has another foreground process group.</p><p>The 4.3 BSD implementation permits the leader (and only member) of the foreground process group to leave the process group bycalling the equivalent of <a href="../functions/setpgid.html"><i>setpgid</i>()</a> and to later return, expecting to return to theforeground. There are no known application needs for this behavior, and IEEE Std 1003.1-2001 neither requires nor forbidsit (except that it is forbidden for session leaders) by leaving it unspecified.</p><h5><a name="tag_01_11_01_03"></a>The Controlling Terminal</h5><p>IEEE Std 1003.1-2001 does not specify a mechanism by which to allocate a controlling terminal. This is normally doneby a system utility (such as <i>getty</i>) and is considered an administrative feature outside the scope ofIEEE Std 1003.1-2001.</p><p>Historical implementations allocate controlling terminals on certain <a href="../functions/open.html"><i>open</i>()</a> calls.Since <a href="../functions/open.html"><i>open</i>()</a> is part of POSIX.1, its behavior had to be dealt with. The traditionalbehavior is not required because it is not very straightforward or flexible for either implementations or applications. However,because of its prevalence, it was not practical to disallow this behavior either. Thus, a mechanism was standardized to ensureportable, predictable behavior in <a href="../functions/open.html"><i>open</i>()</a>.</p><p>Some historical implementations deallocate a controlling terminal on the last system-wide close. This behavior in neitherrequired nor prohibited. Even on implementations that do provide this behavior, applications generally cannot depend on it due toits system-wide nature.</p><h5><a name="tag_01_11_01_04"></a>Terminal Access Control</h5><p>The access controls described in this section apply only to a process that is accessing its controlling terminal. A processaccessing a terminal that is not its controlling terminal is effectively treated the same as a member of the foreground processgroup. While this may seem unintuitive, note that these controls are for the purpose of job control, not security, and job controlrelates only to a process' controlling terminal. Normal file access permissions handle security.</p><p>If the process calling <a href="../functions/read.html"><i>read</i>()</a> or <a href="../functions/write.html"><i>write</i>()</a> is in a background process group that is orphaned, it is not desirable to stop theprocess group, as it is no longer under the control of a job control shell that could put it into the foreground again.Accordingly, calls to <a href="../functions/read.html"><i>read</i>()</a> or <a href="../functions/write.html"><i>write</i>()</a>functions by such processes receive an immediate error return. This is different from 4.2 BSD, which kills orphaned processes thatreceive terminal stop signals.</p>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -