170 lines
10 KiB
HTML
170 lines
10 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_08"></a>Environment Variables</h3>
|
|
|
|
<h4><a name="tag_01_08_01"></a>Environment Variable Definition</h4>
|
|
|
|
<p>The variable <i>environ</i> is not intended to be declared in any header, but rather to be declared by the user for accessing
|
|
the array of strings that is the environment. This is the traditional usage of the symbol. Putting it into a header could break
|
|
some programs that use the symbol for their own purposes.</p>
|
|
|
|
<p>The decision to restrict conforming systems to the use of digits, uppercase letters, and underscores for environment variable
|
|
names allows applications to use lowercase letters in their environment variable names without conflicting with any conforming
|
|
system.</p>
|
|
|
|
<p>In addition to the obvious conflict with the shell syntax for positional parameter substitution, some historical applications
|
|
(including some shells) exclude names with leading digits from the environment.</p>
|
|
|
|
<h4><a name="tag_01_08_02"></a>Internationalization Variables</h4>
|
|
|
|
<p>The text about locale implies that any utilities written in standard C and conforming to IEEE Std 1003.1-2001 must
|
|
issue the following call:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
<tt>setlocale(LC_ALL, "")
|
|
</tt>
|
|
</pre>
|
|
</blockquote>
|
|
|
|
<p>If this were omitted, the ISO C standard specifies that the C locale would be used.</p>
|
|
|
|
<p>If any of the environment variables are invalid, it makes sense to default to an implementation-defined, consistent locale
|
|
environment. It is more confusing for a user to have partial settings occur in case of a mistake. All utilities would then behave
|
|
in one language/cultural environment. Furthermore, it provides a way of forcing the whole environment to be the
|
|
implementation-defined default. Disastrous results could occur if a pipeline of utilities partially uses the environment variables
|
|
in different ways. In this case, it would be appropriate for utilities that use <i>LANG</i> and related variables to exit with an
|
|
error if any of the variables are invalid. For example, users typing individual commands at a terminal might want <a href=
|
|
"../utilities/date.html"><i>date</i></a> to work if <i>LC_MONETARY</i> is invalid as long as <i>LC_TIME</i> is valid. Since these
|
|
are conflicting reasonable alternatives, IEEE Std 1003.1-2001 leaves the results unspecified if the locale environment
|
|
variables would not produce a complete locale matching the specification of the user.</p>
|
|
|
|
<p>The locale settings of individual categories cannot be truly independent and still guarantee correct results. For example, when
|
|
collating two strings, characters must first be extracted from each string (governed by <i>LC_CTYPE )</i> before being mapped to
|
|
collating elements (governed by <i>LC_COLLATE )</i> for comparison. That is, if <i>LC_CTYPE</i> is causing parsing according to the
|
|
rules of a large, multi-byte code set (potentially returning 20000 or more distinct character codeset values), but
|
|
<i>LC_COLLATE</i> is set to handle only an 8-bit codeset with 256 distinct characters, meaningful results are obviously
|
|
impossible.</p>
|
|
|
|
<p>The <i>LC_MESSAGES</i> variable affects the language of messages generated by the standard utilities.</p>
|
|
|
|
<p>The description of the environment variable names starting with the characters "LC_" acknowledges the fact that the interfaces
|
|
presented may be extended as new international functionality is required. In the ISO C standard, names preceded by "LC_" are
|
|
reserved in the name space for future categories.</p>
|
|
|
|
<p>To avoid name clashes, new categories and environment variables are divided into two classifications:
|
|
"implementation-independent" and "implementation-defined".</p>
|
|
|
|
<p>Implementation-independent names will have the following format:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
<tt>LC_</tt><i>NAME</i>
|
|
</pre>
|
|
</blockquote>
|
|
|
|
<p>where <i>NAME</i> is the name of the new category and environment variable. Capital letters must be used for
|
|
implementation-independent names.</p>
|
|
|
|
<p>Implementation-defined names must be in lowercase letters, as below:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
<tt>LC_</tt><i>name</i>
|
|
</pre>
|
|
</blockquote>
|
|
|
|
<h4><a name="tag_01_08_03"></a>Other Environment Variables</h4>
|
|
|
|
<h5><a name="tag_01_08_03_01"></a>COLUMNS, LINES</h5>
|
|
|
|
<p>The default values for the number of column positions, <i>COLUMNS ,</i> and screen height, <i>LINES ,</i> are unspecified
|
|
because historical implementations use different methods to determine values corresponding to the size of the screen in which the
|
|
utility is run. This size is typically known to the implementation through the value of <i>TERM ,</i> or by more elaborate methods
|
|
such as extensions to the <a href="../utilities/stty.html"><i>stty</i></a> utility or knowledge of how the user is dynamically
|
|
resizing windows on a bit-mapped display terminal. Users should not need to set these variables in the environment unless there is
|
|
a specific reason to override the default behavior of the implementation, such as to display data in an area arbitrarily smaller
|
|
than the terminal or window. Values for these variables that are not decimal integers greater than zero are implicitly undefined
|
|
values; it is unnecessary to enumerate all of the possible values outside of the acceptable set.</p>
|
|
|
|
<h5><a name="tag_01_08_03_02"></a>LOGNAME</h5>
|
|
|
|
<p>In most implementations, the value of such a variable is easily forged, so security-critical applications should rely on other
|
|
means of determining user identity. <i>LOGNAME</i> is required to be constructed from the portable filename character set for
|
|
reasons of interchange. No diagnostic condition is specified for violating this rule, and no requirement for enforcement exists.
|
|
The intent of the requirement is that if extended characters are used, the "guarantee" of portability implied by a standard is
|
|
void.</p>
|
|
|
|
<h5><a name="tag_01_08_03_03"></a>PATH</h5>
|
|
|
|
<p>Many historical implementations of the Bourne shell do not interpret a trailing colon to represent the current working directory
|
|
and are thus non-conforming. The C Shell and the KornShell conform to IEEE Std 1003.1-2001 on this point. The usual name
|
|
of dot may also be used to refer to the current working directory.</p>
|
|
|
|
<p>Many implementations historically have used a default value of <b>/bin</b> and <b>/usr/bin</b> for the <i>PATH</i> variable.
|
|
IEEE Std 1003.1-2001 does not mandate this default path be identical to that retrieved from <i>getconf</i> _CS_PATH
|
|
because it is likely that the standardized utilities may be provided in another directory separate from the directories used by
|
|
some historical applications.</p>
|
|
|
|
<h5><a name="tag_01_08_03_04"></a>SHELL</h5>
|
|
|
|
<p>The <i>SHELL</i> variable names the preferred shell of the user; it is a guide to applications. There is no direct requirement
|
|
that that shell conform to IEEE Std 1003.1-2001; that decision should rest with the user. It is the intention of the
|
|
standard developers that alternative shells be permitted, if the user chooses to develop or acquire one. An operating system that
|
|
builds its shell into the "kernel" in such a manner that alternative shells would be impossible does not conform to the spirit of
|
|
IEEE Std 1003.1-2001.</p>
|
|
|
|
<h5><a name="tag_01_08_03_05"></a>TZ</h5>
|
|
|
|
<p>The quoted form of the timezone variable allows timezone names of the form UTC+1 (or any name that contains the character plus (
|
|
<tt>'+'</tt> ), the character minus ( <tt>'-'</tt> ), or digits), which may be appropriate for countries that do not have an
|
|
official timezone name. It would be coded as <UTC+1>+1<UTC+2>, which would cause <i>std</i> to have a value of UTC+1
|
|
and <i>dst</i> a value of UTC+2, each with a length of 5 characters. This does not appear to conflict with any existing usage. The
|
|
characters <tt>'<'</tt> and <tt>'>'</tt> were chosen for quoting because they are easier to parse visually than a quoting
|
|
character that does not provide some sense of bracketing (and in a string like this, such bracketing is helpful). They were also
|
|
chosen because they do not need special treatment when assigning to the <i>TZ</i> variable. Users are often confused by embedding
|
|
quotes in a string. Because <tt>'<'</tt> and <tt>'>'</tt> are meaningful to the shell, the whole string would have to be
|
|
quoted, but that is easily explained. (Parentheses would have presented the same problems.) Although the <tt>'>'</tt> symbol
|
|
could have been permitted in the string by either escaping it or doubling it, it seemed of little value to require that. This could
|
|
be provided as an extension if there was a need. Timezone names of this new form lead to a requirement that the value of
|
|
{_POSIX_TZNAME_MAX} change from 3 to 6.</p>
|
|
|
|
<p>Since the <i>TZ</i> environment variable is usually inherited by all applications started by a user after the value of the
|
|
<i>TZ</i> environment variable is changed and since many applications run using the C or POSIX locale, using characters that are
|
|
not in the portable character set in the <i>std</i> and <i>dst</i> fields could cause unexpected results.</p>
|
|
|
|
<p>The format of the <i>TZ</i> environment variable is changed in Issue 6 to allow for the quoted form, as defined in previous
|
|
versions of the ISO POSIX-1 standard.</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>
|
|
|