summaryrefslogtreecommitdiffstats
path: root/man-pages-posix-2017/man3p/getenv.3p
blob: d7ea8580b9efae84ea6bcf1ab739bbfad6929fc2 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
'\" 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 .