GETENV(3) Library Functions Manual GETENV(3)

getenv — get value of an environment variable

#include <stdlib.h>

char *getenv(const char *name);

[CX] 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 IEEE Std 1003.1-2001 (“POSIX.1”) defers to the ISO C standard.

The getenv () function shall search the environment of the calling process (see the Base Definitions volume of IEEE Std 1003.1-2001 (“POSIX.1”), xbd_chap08(7)) 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 modify the string pointed to by the getenv () function.

The string pointed to may be overwritten by a subsequent call to getenv (), [CX] setenv(3), or unsetenv(3), but shall not be overwritten by a call to any other function in this volume of IEEE Std 1003.1-2001 (“POSIX.1”).

[CX] If the application modifies environ or the pointers to which it points, the behavior 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.

Upon successful completion, getenv () shall return a pointer to a string containing the 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 (), [CX] setenv(3), or unsetenv(3).

On XSI-conformant systems, the return value from getenv () may point to static data which may also be overwritten by subsequent calls to putenv(3).

No errors are defined.

The following example gets the value of the environment variable.

#include <stdlib.h>
...
const char *name = "HOME";
char *value;


value = getenv(name);

None.

The () function was considered but rejected. The putenv(3) function has now been included for alignment with the Single UNIX Specification.

The getenv () function is inherently not reentrant because it returns a value pointing 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(3) or unsetenv(3)), or keeping track of which strings are currently in allocated 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(3) is called. A C runtime start-up procedure (that which invokes () 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(3) or unsetenv(3) 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(1), which attempts to use or really almost any utility ( 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 implementations.

The POSIX Threads Extension states that multi-threaded applications must not modify environ directly, and that IEEE Std 1003.1-2001 (“POSIX.1”) 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.

None.

exec(3), putenv(3), setenv(3), unsetenv(3), the Base Definitions volume of IEEE Std 1003.1-2001 (“POSIX.1”), xbd_chap08(7), <stdlib.h>

First released in Issue 1. Derived from Issue 1 of the SVID.

Normative text previously in the APPLICATION USAGE section is moved to the RETURN VALUE section.

A note indicating that this function need not be reentrant is added to the DESCRIPTION.

The following changes were made to align with the IEEE P1003.1a draft standard:

The DESCRIPTION is updated to avoid use of the term "must" for application requirements.

footer end

January 1, 2004 posix.fail