1 files changed, 220 insertions, 0 deletions
diff --git a/man-pages-posix-2013/man3p/getenv.3p b/man-pages-posix-2013/man3p/getenv.3p
new file mode 100644
index 0000000..99c8cfd
--- /dev/null
+++ b/man-pages-posix-2013/man3p/getenv.3p
@@ -0,0 +1,220 @@
+'\" et
+.TH GETENV "3P" 2013 "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\(hy2008 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\(hy2008,
+.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(),
+or (if supported)
+\fIputenv\fR()
+but they shall not be affected by a call to any other function in this volume of POSIX.1\(hy2008.
+.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
+\fB
+#include <stdlib.h>
+\&...
+const char *name = "HOME";
+char *value;
+.P
+value = getenv(name);
+.fi \fR
+.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\(hy2008,
+.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, 2013 Edition, Standard for Information Technology
+-- Portable Operating System Interface (POSIX), The Open Group Base
+Specifications Issue 7, Copyright (C) 2013 by the Institute of
+Electrical and Electronics Engineers, Inc and The Open Group.
+(This is POSIX.1-2008 with the 2013 Technical Corrigendum 1 applied.) 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.unix.org/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 .