📄 xbd_chap12.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_12"></a>Utility Conventions</h3><h4><a name="tag_01_12_01"></a>Utility Argument Syntax</h4><p>The standard developers considered that recent trends toward diluting the SYNOPSIS sections of historical reference pages to theequivalent of:</p><blockquote><pre><tt>command</tt> <b>[</b><i>options</i><b>][</b><i>operands</i><b>]</b></pre></blockquote><p>were a disservice to the reader. Therefore, considerable effort was placed into rigorous definitions of all the command linearguments and their interrelationships. The relationships depicted in the synopses are normative parts ofIEEE Std 1003.1-2001; this information is sometimes repeated in textual form, but that is only for clarity withincontext.</p><p>The use of "undefined" for conflicting argument usage and for repeated usage of the same option is meant to prevent conformingapplications from using conflicting arguments or repeated options unless specifically allowed (as is the case with <a href="../utilities/ls.html"><i>ls</i></a>, which allows simultaneous, repeated use of the <b>-C</b>, <b>-l</b>, and <b>-1</b> options).Many historical implementations will tolerate this usage, choosing either the first or the last applicable argument. This tolerancecan continue, but conforming applications cannot rely upon it. (Other implementations may choose to print usage messagesinstead.)</p><p>The use of "undefined" for conflicting argument usage also allows an implementation to make reasonable extensions to utilitieswhere the implementor considers mutually-exclusive options according to IEEE Std 1003.1-2001 to have a sensible meaningand result.</p><p>IEEE Std 1003.1-2001 does not define the result of a command when an option-argument or operand is not followed byellipses and the application specifies more than one of that option-argument or operand. This allows an implementation to definevalid (although non-standard) behavior for the utility when more than one such option or operand is specified.</p><p>The following table summarizes the requirements for option-arguments:</p><center><table border="1" cellpadding="3" align="center"><tr valign="top"><th align="center"><p class="tent"> </p></th><th colspan="3" align="center"><p class="tent"><b>SYNOPSIS Shows:</b></p></th></tr><tr valign="top"><th align="center"><p class="tent"> </p></th><th colspan="3" align="center"><p class="tent"><b>_</b></p></th></tr><tr valign="top"><td align="right"><p class="tent"> </p></td><td align="center"><p class="tent">-a <i>arg</i></p></td><td align="center"><p class="tent">-b<i>arg</i></p></td><td align="center"><p class="tent">-c[<i>arg</i>]</p></td></tr><tr valign="top"><td align="right"><p class="tent">Conforming</p></td><td align="center"><p class="tent"> </p></td><td align="center"><p class="tent"> </p></td><td align="center"><p class="tent"> </p></td></tr><tr valign="top"><td align="right"><p class="tent">application uses:</p></td><td align="center"><p class="tent">-a <i>arg</i></p></td><td align="center"><p class="tent">-b<i>arg</i></p></td><td align="center"><p class="tent">-c<i>arg</i> or <tt>-c</tt></p></td></tr><tr valign="top"><td align="right"><p class="tent">System supports:</p></td><td align="center"><p class="tent">-a <i>arg</i> and <tt>-a</tt><i>arg</i></p></td><td align="center"><p class="tent">-b <i>arg</i> and <i>-barg</i></p></td><td align="center"><p class="tent">-carg and <tt>-c</tt></p></td></tr><tr valign="top"><td align="right"><p class="tent">Non-conforming</p></td><td align="center"><p class="tent"> </p></td><td align="center"><p class="tent"> </p></td><td align="center"><p class="tent"> </p></td></tr><tr valign="top"><td align="right"><p class="tent">applications may use:</p></td><td align="center"><p class="tent">-a<i>arg</i></p></td><td align="center"><p class="tent">-b <i>arg</i></p></td><td align="center"><p class="tent">N/A</p></td></tr></table></center><p>Allowing <blank>s after an option (that is, placing an option and its option-argument into separate argument strings) whenIEEE Std 1003.1-2001 does not require it encourages portability of users, while still preserving backwards-compatibilityof scripts. Inserting <blank>s between the option and the option-argument is preferred; however, historical usage has notbeen consistent in this area; therefore, <blank>s are required to be handled by all implementations, but implementations arealso allowed to handle the historical syntax. Another justification for selecting the multiple-argument method was that thesingle-argument case is inherently ambiguous when the option-argument can legitimately be a null string.</p><p>IEEE Std 1003.1-2001 explicitly states that digits are permitted as operands and option-arguments. The lower and upperbounds for the values of the numbers used for operands and option-arguments were derived from the ISO C standard values for{LONG_MIN} and {LONG_MAX}. The requirement on the standard utilities is that numbers in the specified range do not cause a syntaxerror, although the specification of a number need not be semantically correct for a particular operand or option-argument of autility. For example, the specification of:</p><blockquote><pre>dd obs=3000000000</pre></blockquote><p>would yield undefined behavior for the application and could be a syntax error because the number 3000000000 is outside of therange -2147483647 to +2147483647. On the other hand:</p><blockquote><pre><tt>dd obs=2000000000</tt></pre></blockquote><p>may cause some error, such as "blocksize too large", rather than a syntax error.</p><h4><a name="tag_01_12_02"></a>Utility Syntax Guidelines</h4><p>This section is based on the rules listed in the SVID. It was included for two reasons:</p><ol><li><p>The individual utility descriptions in the Shell and Utilities volume of IEEE Std 1003.1-2001, <a href="../utilities/xcu_chap04.html">Chapter 4, Utilities</a> needed a set of common (although not universal) actions on which they couldanchor their descriptions of option and operand syntax. Most of the standard utilities actually do use these guidelines, and manyof their historical implementations use the <a href="../functions/getopt.html"><i>getopt</i>()</a> function for their parsing.Therefore, it was simpler to cite the rules and merely identify exceptions.</p></li><li><p>Writers of conforming applications need suggested guidelines if the POSIX community is to avoid the chaos of historical UNIXsystem command syntax.</p></li></ol><p>It is recommended that all <i>future</i> utilities and applications use these guidelines to enhance "user portability". Thefact that some historical utilities could not be changed (to avoid breaking historical applications) should not deter this futuregoal.</p><p>The voluntary nature of the guidelines is highlighted by repeated uses of the word <i>should</i> throughout. This usage shouldnot be misinterpreted to imply that utilities that claim conformance in their OPTIONS sections do not always conform.</p><p>Guidelines 1 and 2 are offered as guidance for locales using Latin alphabets. No recommendations are made byIEEE Std 1003.1-2001 concerning utility naming in other locales.</p><p>In the Shell and Utilities volume of IEEE Std 1003.1-2001, <a href="../utilities/xcu_chap02.html#tag_02_09_01">Section2.9.1, Simple Commands</a>, it is further stated that a command used in the Shell Command Language cannot be named with a trailingcolon.</p><p>Guideline 3 was changed to allow alphanumeric characters (letters and digits) from the character set to allow compatibility withhistorical usage. Historical practice allows the use of digits wherever practical, and there are no portability issues that wouldprohibit the use of digits. In fact, from an internationalization viewpoint, digits (being non-language-dependent) are preferableover letters (a <b>-2</b> is intuitively self-explanatory to any user, while in the <b>-f</b> <i>filename</i> the letter<tt>'f'</tt> is a mnemonic aid only to speakers of Latin-based languages where "filename" happens to translate to a word thatbegins with <tt>'f'</tt> . Since guideline 3 still retains the word "single", multi-digit options are not allowed. Instances ofhistorical utilities that used them have been marked obsolescent, with the numbers being changed from option names tooption-arguments.</p><p>It was difficult to achieve a satisfactory solution to the problem of name space in option characters. When the standarddevelopers desired to extend the historical <i>cc</i> utility to accept ISO C standard programs, they found that all of theportable alphabet was already in use by various vendors. Thus, they had to devise a new name, <i>c89</i> (now superseded by <ahref="../utilities/c99.html"><i>c99</i></a>), rather than something like <i>cc</i> <b>-X</b>. There were suggestions thatimplementors be restricted to providing extensions through various means (such as using a plus sign as the option delimiter orusing option characters outside the alphanumeric set) that would reserve all of the remaining alphanumeric characters for futurePOSIX standards. These approaches were resisted because they lacked the historical style of UNIX systems. Furthermore, if avendor-provided option should become commonly used in the industry, it would be a candidate for standardization. It would bedesirable to standardize such a feature using historical practice for the syntax (the semantics can be standardized with anysyntax). This would not be possible if the syntax was one reserved for the vendor. However, since the standardization process maylead to minor changes in the semantics, it may prove to be better for a vendor to use a syntax that will not be affected bystandardization.</p><p>Guideline 8 includes the concept of comma-separated lists in a single argument. It is up to the utility to parse such a listitself because <a href="../functions/getopt.html"><i>getopt</i>()</a> just returns the single string. This situation was retainedso that certain historical utilities would not violate the guidelines. Applications preparing for international use should be awareof an occasional problem with comma-separated lists: in some locales, the comma is used as the radix character. Thus, if anapplication is preparing operands for a utility that expects a comma-separated list, it should avoid generating non-integer valuesthrough one of the means that is influenced by setting the <i>LC_NUMERIC</i> variable (such as <a href="../utilities/awk.html"><i>awk</i></a>, <a href="../utilities/bc.html"><i>bc</i></a>, <a href="../utilities/printf.html"><i>printf</i></a>, or <a href="../functions/printf.html"><i>printf</i>()</a>).</p><p>Applications calling any utility with a first operand starting with <tt>'-'</tt> should usually specify <b>--</b>, as indicatedby Guideline 10, to mark the end of the options. This is true even if the SYNOPSIS in the Shell and Utilities volume ofIEEE Std 1003.1-2001 does not specify any options; implementations may provide options as extensions to the Shell andUtilities volume of IEEE Std 1003.1-2001. The standard utilities that do not support Guideline 10 indicate that fact inthe OPTIONS section of the utility description.</p><p>Guideline 11 was modified to clarify that the order of different options should not matter relative to one another. However, theorder of repeated options that also have option-arguments may be significant; therefore, such options are required to beinterpreted in the order that they are specified. The <a href="../utilities/make.html"><i>make</i></a> utility is an instance of ahistorical utility that uses repeated options in which the order is significant. Multiple files are specified by giving multipleinstances of the <b>-f</b> option; for example:</p><blockquote><pre><tt>make -f common_header -f specific_rules target</tt></pre></blockquote><p>Guideline 13 does not imply that all of the standard utilities automatically accept the operand <tt>'-'</tt> to mean standardinput or output, nor does it specify the actions of the utility upon encountering multiple <tt>'-'</tt> operands. It simply saysthat, by default, <tt>'-'</tt> operands are not used for other purposes in the file reading or writing (but not when using <a href="../functions/stat.html"><i>stat</i>()</a>, <a href="../functions/unlink.html"><i>unlink</i>()</a>, <a href="../utilities/touch.html"><i>touch</i></a>, and so on) utilities. All information concerning actual treatment of the <tt>'-'</tt>operand is found in the individual utility sections.</p><p>An area of concern was that as implementations mature, implementation-defined utilities and implementation-defined utilityoptions will result. The idea was expressed that there needed to be a standard way, say an environment variable or some suchmechanism, to identify implementation-defined utilities separately from standard utilities that may have the same name. It wasdecided that there already exist several ways of dealing with this situation and that it is outside of the scope to attempt tostandardize in the area of non-standard items. A method that exists on some historical implementations is the use of the so-called<b>/local/bin</b> or <b>/usr/local/bin</b> directory to separate local or additional copies or versions of utilities. Anothermethod that is also used is to isolate utilities into completely separate domains. Still another method to ensure that the desiredutility is being used is to request the utility by its full pathname. There are many approaches to this situation; the examplesgiven above serve to illustrate that there is more than one.</p><hr size="2" noshade><center><font size="2"><!--footer start-->UNIX ® is a registered Trademark of The Open Group.<br>POSIX ® is a registered Trademark of The IEEE.<br>[ <a href="../mindex.html">Main Index</a> | <a href="../basedefs/contents.html">XBD</a> | <a href="../utilities/contents.html">XCU</a> | <a href="../functions/contents.html">XSH</a> | <a href="../xrat/contents.html">XRAT</a>]</font></center><!--footer end--><hr size="2" noshade></body></html>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -