GETENV(3)                  POSIX Programmer's Manual                 GETENV(3)



PPRROOLLOOGG
       This manual page is part of the POSIX Programmer's Manual.  The OS
       implementation of this interface may differ (consult the corresponding
       OS manual page for details of OS behavior), or the interface may not be
       implemented on OS.

NNAAMMEE
       getenv -- get value of an environment variable

SSYYNNOOPPSSIISS
       #include <stdlib.h>

       char *getenv(const char *_n_a_m_e);

DDEESSCCRRIIPPTTIIOONN
       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-2017
       defers to the ISO C standard.

       The _g_e_t_e_n_v() function shall search the environment of the calling
       process (see the Base Definitions volume of POSIX.1-2017, _C_h_a_p_t_e_r _8,
       _E_n_v_i_r_o_n_m_e_n_t _V_a_r_i_a_b_l_e_s) for the environment variable _n_a_m_e 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 _g_e_t_e_n_v() function.

       The returned string pointer might be invalidated or the string content
       might be overwritten by a subsequent call to _g_e_t_e_n_v(), _s_e_t_e_n_v(),
       _u_n_s_e_t_e_n_v(),
       or (if supported) _p_u_t_e_n_v() but they shall not be affected by a call to
       any other function in this volume of POSIX.1-2017.

       The returned string pointer might also be invalidated if the calling
       thread is terminated.

       The _g_e_t_e_n_v() function need not be thread-safe.

RREETTUURRNN VVAALLUUEE
       Upon successful completion, _g_e_t_e_n_v() shall return a pointer to a string
       containing the _v_a_l_u_e for the specified _n_a_m_e.  If the specified _n_a_m_e
       cannot be found in the environment of the calling process, a null
       pointer shall be returned.

EERRRROORRSS
       No errors are defined.

       _T_h_e _f_o_l_l_o_w_i_n_g _s_e_c_t_i_o_n_s _a_r_e _i_n_f_o_r_m_a_t_i_v_e_.

EEXXAAMMPPLLEESS
   GGeettttiinngg tthhee VVaalluuee ooff aann EEnnvviirroonnmmeenntt VVaarriiaabbllee
       The following example gets the value of the _H_O_M_E environment variable.


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

           value = getenv(name);

AAPPPPLLIICCAATTIIOONN UUSSAAGGEE
       None.

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

       The _g_e_t_e_n_v() function is inherently not thread-safe because it returns
       a value pointing to static data.

       Conforming applications are required not to directly modify the
       pointers to which _e_n_v_i_r_o_n points, but to use only the _s_e_t_e_n_v(),
       _u_n_s_e_t_e_n_v(), and _p_u_t_e_n_v() functions, or assignment to _e_n_v_i_r_o_n 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 _e_n_v_i_r_o_n when _u_n_s_e_t_e_n_v() is
       called. A C runtime start-up procedure (that which invokes _m_a_i_n() and
       perhaps initializes _e_n_v_i_r_o_n) 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 _e_n_v_i_r_o_n, this can be detected by _g_e_t_e_n_v(), _s_e_t_e_n_v(),
       _u_n_s_e_t_e_n_v(), or _p_u_t_e_n_v() 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 _e_n_v_i_r_o_n to point
       to it.)

       In fact, for higher performance of _g_e_t_e_n_v(), implementations that do
       not provide _p_u_t_e_n_v() 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 _e_n_v_i_r_o_n when _s_e_t_e_n_v() or _u_n_s_e_t_e_n_v() is
       invoked. On implementations that do provide _p_u_t_e_n_v(), 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 _p_u_t_e_n_v().  For example, if an environment string found by
       searching the copy is one that was added using _p_u_t_e_n_v(), the
       implementation would need to check that the string in _e_n_v_i_r_o_n 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 _e_n_v_i_r_o_n that was added using
       _p_u_t_e_n_v() in case any of them have changed their names and now match.
       Thus, each use of _p_u_t_e_n_v() to add to the environment would reduce the
       speed advantage of having the copy.

       Performance of _g_e_t_e_n_v() 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 _l_s, which attempts to use _C_O_L_U_M_N_S), or really almost
       any utility (_L_A_N_G, _L_C___A_L_L, 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.

FFUUTTUURREE DDIIRREECCTTIIOONNSS
       A future version may add one or more functions to access and modify the
       environment in a thread-safe manner.

SSEEEE AALLSSOO
       _e_x_e_c, _p_u_t_e_n_v(), _s_e_t_e_n_v(), _u_n_s_e_t_e_n_v()

       The Base Definitions volume of POSIX.1-2017, _C_h_a_p_t_e_r _8, _E_n_v_i_r_o_n_m_e_n_t
       _V_a_r_i_a_b_l_e_s, <<ssttddlliibb..hh>>

CCOOPPYYRRIIGGHHTT
       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 .

       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 .



IEEE/The Open Group                  2017                            GETENV(3)
