311 lines
15 KiB
HTML
311 lines
15 KiB
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 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-2001<br>
|
|
Copyright © 2001 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 the
|
|
equivalent 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 line
|
|
arguments and their interrelationships. The relationships depicted in the synopses are normative parts of
|
|
IEEE Std 1003.1-2001; this information is sometimes repeated in textual form, but that is only for clarity within
|
|
context.</p>
|
|
|
|
<p>The use of "undefined" for conflicting argument usage and for repeated usage of the same option is meant to prevent conforming
|
|
applications 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 tolerance
|
|
can continue, but conforming applications cannot rely upon it. (Other implementations may choose to print usage messages
|
|
instead.)</p>
|
|
|
|
<p>The use of "undefined" for conflicting argument usage also allows an implementation to make reasonable extensions to utilities
|
|
where the implementor considers mutually-exclusive options according to IEEE Std 1003.1-2001 to have a sensible meaning
|
|
and 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 by
|
|
ellipses and the application specifies more than one of that option-argument or operand. This allows an implementation to define
|
|
valid (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) when
|
|
IEEE Std 1003.1-2001 does not require it encourages portability of users, while still preserving backwards-compatibility
|
|
of scripts. Inserting <blank>s between the option and the option-argument is preferred; however, historical usage has not
|
|
been consistent in this area; therefore, <blank>s are required to be handled by all implementations, but implementations are
|
|
also allowed to handle the historical syntax. Another justification for selecting the multiple-argument method was that the
|
|
single-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 upper
|
|
bounds 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 syntax
|
|
error, although the specification of a number need not be semantically correct for a particular operand or option-argument of a
|
|
utility. 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 the
|
|
range -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 could
|
|
anchor their descriptions of option and operand syntax. Most of the standard utilities actually do use these guidelines, and many
|
|
of 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 UNIX
|
|
system command syntax.</p>
|
|
</li>
|
|
</ol>
|
|
|
|
<p>It is recommended that all <i>future</i> utilities and applications use these guidelines to enhance "user portability". The
|
|
fact that some historical utilities could not be changed (to avoid breaking historical applications) should not deter this future
|
|
goal.</p>
|
|
|
|
<p>The voluntary nature of the guidelines is highlighted by repeated uses of the word <i>should</i> throughout. This usage should
|
|
not 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 by
|
|
IEEE 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">Section
|
|
2.9.1, Simple Commands</a>, it is further stated that a command used in the Shell Command Language cannot be named with a trailing
|
|
colon.</p>
|
|
|
|
<p>Guideline 3 was changed to allow alphanumeric characters (letters and digits) from the character set to allow compatibility with
|
|
historical usage. Historical practice allows the use of digits wherever practical, and there are no portability issues that would
|
|
prohibit the use of digits. In fact, from an internationalization viewpoint, digits (being non-language-dependent) are preferable
|
|
over 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 that
|
|
begins with <tt>'f'</tt> . Since guideline 3 still retains the word "single", multi-digit options are not allowed. Instances of
|
|
historical utilities that used them have been marked obsolescent, with the numbers being changed from option names to
|
|
option-arguments.</p>
|
|
|
|
<p>It was difficult to achieve a satisfactory solution to the problem of name space in option characters. When the standard
|
|
developers desired to extend the historical <i>cc</i> utility to accept ISO C standard programs, they found that all of the
|
|
portable alphabet was already in use by various vendors. Thus, they had to devise a new name, <i>c89</i> (now superseded by <a
|
|
href="../utilities/c99.html"><i>c99</i></a>), rather than something like <i>cc</i> <b>-X</b>. There were suggestions that
|
|
implementors be restricted to providing extensions through various means (such as using a plus sign as the option delimiter or
|
|
using option characters outside the alphanumeric set) that would reserve all of the remaining alphanumeric characters for future
|
|
POSIX standards. These approaches were resisted because they lacked the historical style of UNIX systems. Furthermore, if a
|
|
vendor-provided option should become commonly used in the industry, it would be a candidate for standardization. It would be
|
|
desirable to standardize such a feature using historical practice for the syntax (the semantics can be standardized with any
|
|
syntax). This would not be possible if the syntax was one reserved for the vendor. However, since the standardization process may
|
|
lead to minor changes in the semantics, it may prove to be better for a vendor to use a syntax that will not be affected by
|
|
standardization.</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 list
|
|
itself because <a href="../functions/getopt.html"><i>getopt</i>()</a> just returns the single string. This situation was retained
|
|
so that certain historical utilities would not violate the guidelines. Applications preparing for international use should be aware
|
|
of an occasional problem with comma-separated lists: in some locales, the comma is used as the radix character. Thus, if an
|
|
application is preparing operands for a utility that expects a comma-separated list, it should avoid generating non-integer values
|
|
through 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 indicated
|
|
by Guideline 10, to mark the end of the options. This is true even if the SYNOPSIS in the Shell and Utilities volume of
|
|
IEEE Std 1003.1-2001 does not specify any options; implementations may provide options as extensions to the Shell and
|
|
Utilities volume of IEEE Std 1003.1-2001. The standard utilities that do not support Guideline 10 indicate that fact in
|
|
the 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, the
|
|
order of repeated options that also have option-arguments may be significant; therefore, such options are required to be
|
|
interpreted in the order that they are specified. The <a href="../utilities/make.html"><i>make</i></a> utility is an instance of a
|
|
historical utility that uses repeated options in which the order is significant. Multiple files are specified by giving multiple
|
|
instances 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 standard
|
|
input or output, nor does it specify the actions of the utility upon encountering multiple <tt>'-'</tt> operands. It simply says
|
|
that, 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 utility
|
|
options will result. The idea was expressed that there needed to be a standard way, say an environment variable or some such
|
|
mechanism, to identify implementation-defined utilities separately from standard utilities that may have the same name. It was
|
|
decided that there already exist several ways of dealing with this situation and that it is outside of the scope to attempt to
|
|
standardize 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. Another
|
|
method that is also used is to isolate utilities into completely separate domains. Still another method to ensure that the desired
|
|
utility is being used is to request the utility by its full pathname. There are many approaches to this situation; the examples
|
|
given 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>
|
|
|