getenv.3p (7045B)
- '\" et
- .TH GETENV "3P" 2017 "IEEE/The Open Group" "POSIX Programmer's Manual"
- .\"
- .SH PROLOG
- This manual page is part of the POSIX Programmer's Manual.
- The Linux implementation of this interface may differ (consult
- the corresponding Linux manual page for details of Linux behavior),
- or the interface may not be implemented on Linux.
- .\"
- .SH NAME
- getenv
- \(em get value of an environment variable
- .SH SYNOPSIS
- .LP
- .nf
- #include <stdlib.h>
- .P
- char *getenv(const char *\fIname\fP);
- .fi
- .SH DESCRIPTION
- The functionality described on this reference page is aligned with the
- ISO\ C standard. Any conflict between the requirements described here and the
- ISO\ C standard is unintentional. This volume of POSIX.1\(hy2017 defers to the ISO\ C standard.
- .P
- The
- \fIgetenv\fR()
- function shall search the environment of the calling process (see the Base Definitions volume of POSIX.1\(hy2017,
- .IR "Chapter 8" ", " "Environment Variables")
- for the environment variable
- .IR 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 modify the string pointed to by the
- \fIgetenv\fR()
- function.
- .P
- The returned string pointer might be invalidated or
- the string content might be overwritten by a subsequent call to
- \fIgetenv\fR(),
- \fIsetenv\fR(),
- \fIunsetenv\fR(),
- .br
- or (if supported)
- \fIputenv\fR()
- but they shall not be affected by a call to any other function in this volume of POSIX.1\(hy2017.
- .P
- The returned string pointer might also be invalidated if the calling
- thread is terminated.
- .P
- The
- \fIgetenv\fR()
- function need not be thread-safe.
- .SH "RETURN VALUE"
- Upon successful completion,
- \fIgetenv\fR()
- shall return a pointer to a string containing the
- .IR value
- for the specified
- .IR name .
- If the specified
- .IR name
- cannot be found in the environment of the calling process, a null
- pointer shall be returned.
- .SH ERRORS
- No errors are defined.
- .LP
- .IR "The following sections are informative."
- .SH EXAMPLES
- .SS "Getting the Value of an Environment Variable"
- .P
- The following example gets the value of the
- .IR HOME
- environment variable.
- .sp
- .RS 4
- .nf
- #include <stdlib.h>
- \&...
- const char *name = "HOME";
- char *value;
- .P
- value = getenv(name);
- .fi
- .P
- .RE
- .SH "APPLICATION USAGE"
- None.
- .SH RATIONALE
- The
- \fIclearenv\fR()
- function was considered but rejected. The
- \fIputenv\fR()
- function has now been included for alignment with the Single UNIX
- Specification.
- .P
- The
- \fIgetenv\fR()
- function is inherently not thread-safe because it returns a value
- pointing to static data.
- .P
- Conforming applications are required not to directly modify the pointers
- to which
- .IR environ
- points, but to use only the
- \fIsetenv\fR(),
- \fIunsetenv\fR(),
- and
- \fIputenv\fR()
- functions, or assignment to
- .IR environ
- itself, to manipulate the process environment. This constraint allows
- the implementation to properly manage the memory it allocates. This
- enables the implementation to free any space it has allocated to strings
- (and perhaps the pointers to them) stored in
- .IR environ
- when
- \fIunsetenv\fR()
- is called. A C runtime start-up procedure (that which invokes
- \fImain\fR()
- and perhaps initializes
- .IR 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. If the application switches to a complete new
- environment by assigning a new value to
- .IR environ ,
- this can be detected by
- \fIgetenv\fR(),
- \fIsetenv\fR(),
- \fIunsetenv\fR(),
- or
- \fIputenv\fR()
- and the implementation can at that point reinitialize based on the new
- environment. (This may include copying the environment strings into a
- new array and assigning
- .IR environ
- to point to it.)
- .P
- In fact, for higher performance of
- \fIgetenv\fR(),
- implementations that do not provide
- \fIputenv\fR()
- 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
- .IR environ
- when
- \fIsetenv\fR()
- or
- \fIunsetenv\fR()
- is invoked. On implementations that do provide
- \fIputenv\fR(),
- such a copy might still be worthwhile but would need to allow for the
- fact that applications can directly modify the content of environment
- strings added with
- \fIputenv\fR().
- For example, if an environment string found by searching the copy is
- one that was added using
- \fIputenv\fR(),
- the implementation would need to check that the string in
- .IR environ
- still has the same name (and value, if the copy includes values), and
- whenever searching the copy produces no match the implementation would
- then need to search each environment string in
- .IR environ
- that was added using
- \fIputenv\fR()
- in case any of them have changed their names and now match. Thus, each
- use of
- \fIputenv\fR()
- to add to the environment would reduce the speed advantage of having
- the copy.
- .P
- Performance of
- \fIgetenv\fR()
- 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
- .IR ls ,
- which attempts to use
- .IR COLUMNS ),
- or really almost any utility (\c
- .IR LANG ,
- .IR LC_ALL ,
- and so on) is similarly slowed down by the linear search through the
- variables.
- .P
- 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 implementations.
- .SH "FUTURE DIRECTIONS"
- A future version may add one or more functions to access and modify the
- environment in a thread-safe manner.
- .SH "SEE ALSO"
- .IR "\fIexec\fR\^",
- .IR "\fIputenv\fR\^(\|)",
- .IR "\fIsetenv\fR\^(\|)",
- .IR "\fIunsetenv\fR\^(\|)"
- .P
- The Base Definitions volume of POSIX.1\(hy2017,
- .IR "Chapter 8" ", " "Environment Variables",
- .IR "\fB<stdlib.h>\fP"
- .\"
- .SH COPYRIGHT
- Portions of this text are reprinted and reproduced in electronic form
- from IEEE Std 1003.1-2017, Standard for Information Technology
- -- Portable Operating System Interface (POSIX), The Open Group Base
- Specifications Issue 7, 2018 Edition,
- Copyright (C) 2018 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 .
- .PP
- Any typographical or formatting errors that appear
- in this page are most likely
- to have been introduced during the conversion of the source files to
- man page format. To report such errors, see
- https://www.kernel.org/doc/man-pages/reporting_bugs.html .