GETENV(P) GETENV(P)
NAME
getenv - get value of an environment variable
SYNOPSIS
#include <stdlib.h>
char *getenv(const char *name);
DESCRIPTION
The getenv() function shall search the environment of the calling process (see the
Base Definitions volume of IEEE Std 1003.1-2001, Chapter 8, Environment Variables)
for the environment variable name if it exists and return a pointer to the value of
the environment variable. If the specified environment variable cannot be found, a
null pointer shall be returned. The application shall ensure that it does not mod-
ify the string pointed to by the getenv() function.
The string pointed to may be overwritten by a subsequent call to getenv(),
setenv(), or unsetenv(), but shall not be overwritten by a call to any other func-
tion in this volume of IEEE Std 1003.1-2001.
If the application modifies environ or the pointers to which it points, the behav-
ior of getenv() is undefined.
The getenv() function need not be reentrant. A function that is not required to be
reentrant is not required to be thread-safe.
RETURN VALUE
Upon successful completion, getenv() shall return a pointer to a string containing
the value for the specified name. If the specified name cannot be found in the
environment of the calling process, a null pointer shall be returned.
The return value from getenv() may point to static data which may be overwritten by
subsequent calls to getenv(), setenv(), or unsetenv().
On XSI-conformant systems, the return value from getenv() may point to static data
which may also be overwritten by subsequent calls to putenv().
ERRORS
No errors are defined.
The following sections are informative.
EXAMPLES
Getting the Value of an Environment Variable
The following example gets the value of the HOME environment variable.
#include <stdlib.h>
...
const char *name = "HOME";
char *value;
value = getenv(name);
APPLICATION USAGE
None.
RATIONALE
The clearenv() function was considered but rejected. The putenv() function has now
been included for alignment with the Single UNIX Specification.
The getenv() function is inherently not reentrant because it returns a value point-
ing to static data.
Conforming applications are required not to modify environ directly, but to use
only the functions described here to manipulate the process environment as an
abstract object. Thus, the implementation of the environment access functions has
complete control over the data structure used to represent the environment (subject
to the requirement that environ be maintained as a list of strings with embedded
equal signs for applications that wish to scan the environment). This constraint
allows the implementation to properly manage the memory it allocates, either by
using allocated storage for all variables (copying them on the first invocation of
setenv() or unsetenv()), or keeping track of which strings are currently in allo-
cated space and which are not, via a separate table or some other means. This
enables the implementation to free any allocated space used by strings (and perhaps
the pointers to them) stored in environ when unsetenv() is called. A C runtime
start-up procedure (that which invokes main() and perhaps initializes environ) can
also initialize a flag indicating that none of the environment has yet been copied
to allocated storage, or that the separate table has not yet been initialized.
In fact, for higher performance of getenv(), the implementation could also maintain
a separate copy of the environment in a data structure that could be searched much
more quickly (such as an indexed hash table, or a binary tree), and update both it
and the linear list at environ when setenv() or unsetenv() is invoked.
Performance of getenv() can be important for applications which have large numbers
of environment variables. Typically, applications like this use the environment as
a resource database of user-configurable parameters. The fact that these variables
are in the user’s shell environment usually means that any other program that uses
environment variables (such as ls, which attempts to use COLUMNS ), or really
almost any utility ( LANG , LC_ALL , and so on) is similarly slowed down by the
linear search through the variables.
An implementation that maintains separate data structures, or even one that manages
the memory it consumes, is not currently required as it was thought it would reduce
consensus among implementors who do not want to change their historical implementa-
tions.
The POSIX Threads Extension states that multi-threaded applications must not modify
environ directly, and that IEEE Std 1003.1-2001 is providing functions which such
applications can use in the future to manipulate the environment in a thread-safe
manner. Thus, moving away from application use of environ is desirable from that
standpoint as well.
FUTURE DIRECTIONS
None.
SEE ALSO
exec() , putenv() , setenv() , unsetenv() , the Base Definitions volume of
IEEE Std 1003.1-2001, Chapter 8, Environment Variables, <stdlib.h>
COPYRIGHT
Portions of this text are reprinted and reproduced in electronic form from IEEE Std
1003.1, 2003 Edition, Standard for Information Technology -- Portable Operating
System Interface (POSIX), The Open Group Base Specifications Issue 6, Copyright (C)
2001-2003 by the Institute of Electrical and Electronics Engineers, Inc and The
Open Group. In the event of any discrepancy between this version and the original
IEEE and The Open Group Standard, the original IEEE and The Open Group Standard is
the referee document. The original Standard can be obtained online at
http://www.opengroup.org/unix/online.html .
POSIX 2003 GETENV(P)
Generated by $Id: phpMan.php,v 4.55 2007/09/05 04:42:51 chedong Exp $ Author: Che Dong
On Apache/1.3.41 (Unix) PHP/5.2.5 mod_perl/1.30 mod_gzip/1.3.26.1a
Under GNU General Public License
2008-12-02 08:19 @38.103.63.58 CrawledBy CCBot/1.0 (+http://www.commoncrawl.org/bot.html)