cpython/Doc/lib/libos.tex

118 lines
4.6 KiB
TeX
Raw Normal View History

\section{Standard Module \module{os}}
\label{module-os}
1994-01-02 01:22:07 +00:00
\stmodindex{os}
1998-03-10 03:17:26 +00:00
1994-01-02 01:22:07 +00:00
This module provides a more portable way of using operating system
(OS) dependent functionality than importing an OS dependent built-in
1998-03-10 03:17:26 +00:00
module like \module{posix}.
1994-01-02 01:22:07 +00:00
1998-03-10 03:17:26 +00:00
When the optional built-in module \module{posix} is available, this
module exports the same functions and data as \module{posix}; otherwise,
it searches for an OS dependent built-in module like \module{mac} and
1994-01-02 01:22:07 +00:00
exports the same functions and data as found there. The design of all
1995-03-13 10:03:32 +00:00
Python's built-in OS dependent modules is such that as long as the same
1994-01-02 01:22:07 +00:00
functionality is available, it uses the same interface; e.g., the
1998-03-10 03:17:26 +00:00
function \code{os.stat(\var{file})} returns stat info about \var{file}
in a format compatible with the \POSIX{} interface.
1994-01-02 01:22:07 +00:00
Extensions peculiar to a particular OS are also available through the
1998-03-10 03:17:26 +00:00
\module{os} module, but using them is of course a threat to
portability!
1994-01-02 01:22:07 +00:00
1998-03-10 03:17:26 +00:00
Note that after the first time \module{os} is imported, there is
\emph{no} performance penalty in using functions from \module{os}
instead of directly from the OS dependent built-in module, so there
should be \emph{no} reason not to use \module{os}!
1994-01-02 01:22:07 +00:00
In addition to whatever the correct OS dependent module exports, the
1998-03-10 03:17:26 +00:00
following variables and functions are always exported by \module{os}:
1994-01-02 01:22:07 +00:00
\begin{datadesc}{name}
The name of the OS dependent module imported. The following names
have currently been registered: \code{'posix'}, \code{'nt'},
\code{'dos'}, \code{'mac'}.
1994-01-02 01:22:07 +00:00
\end{datadesc}
\begin{datadesc}{path}
The corresponding OS dependent standard module for pathname
1998-03-10 03:17:26 +00:00
operations, e.g., \module{posixpath} or \module{macpath}. Thus, (given
1994-01-02 01:22:07 +00:00
the proper imports), \code{os.path.split(\var{file})} is equivalent to but
more portable than \code{posixpath.split(\var{file})}.
\end{datadesc}
\begin{datadesc}{curdir}
The constant string used by the OS to refer to the current directory,
1998-03-10 03:17:26 +00:00
e.g. \code{'.'} for \POSIX{} or \code{':'} for the Macintosh.
1994-01-02 01:22:07 +00:00
\end{datadesc}
\begin{datadesc}{pardir}
The constant string used by the OS to refer to the parent directory,
1998-03-10 03:17:26 +00:00
e.g. \code{'..'} for \POSIX{} or \code{'::'} for the Macintosh.
1994-01-02 01:22:07 +00:00
\end{datadesc}
\begin{datadesc}{sep}
The character used by the OS to separate pathname components,
1998-03-10 03:17:26 +00:00
e.g. \code{'/'} for \POSIX{} or \code{':'} for the Macintosh. Note that
knowing this is not sufficient to be able to parse or concatenate
1998-03-10 03:17:26 +00:00
pathnames --- better use \function{os.path.split()} and
\function{os.path.join()}---but it is occasionally useful.
1994-01-02 01:22:07 +00:00
\end{datadesc}
\begin{datadesc}{altsep}
An alternative character used by the OS to separate pathname components,
or \code{None} if only one separator character exists. This is set to
\code{'/'} on DOS/Windows systems where \code{sep} is a backslash.
\end{datadesc}
\begin{datadesc}{pathsep}
The character conventionally used by the OS to separate search patch
components (as in \code{\$PATH}), e.g.\ \code{':'} for \POSIX{} or
\code{';'} for MS-DOS.
\end{datadesc}
\begin{datadesc}{linesep}
The string used to separate (or, rather, terminate) lines on the
current platform. This may be a single character, e.g. \code{'\e n'}
for \POSIX{} or \code{'\e r'} for MacOS, or multiple characters,
e.g. \code{'\e r\e n'} for MS-DOS.
\end{datadesc}
\begin{datadesc}{defpath}
1998-03-10 03:17:26 +00:00
The default search path used by \code{exec*p*()} if the environment
doesn't have a \code{'PATH'} key.
\end{datadesc}
1998-03-10 03:17:26 +00:00
\begin{funcdesc}{execl}{path, arg0, arg1, ...}
This is equivalent to
1998-03-10 03:17:26 +00:00
\code{execv(\var{path}, (\var{arg0}, \var{arg1}, ...))}.
1994-01-02 01:22:07 +00:00
\end{funcdesc}
1998-03-10 03:17:26 +00:00
\begin{funcdesc}{execle}{path, arg0, arg1, ..., env}
This is equivalent to
1998-03-10 03:17:26 +00:00
\code{execve(\var{path}, (\var{arg0}, \var{arg1}, ...), \var{env})}.
1994-01-02 01:22:07 +00:00
\end{funcdesc}
1998-03-10 03:17:26 +00:00
\begin{funcdesc}{execlp}{path, arg0, arg1, ...}
This is equivalent to
1998-03-10 03:17:26 +00:00
\code{execvp(\var{path}, (\var{arg0}, \var{arg1}, ...))}.
\end{funcdesc}
1998-03-10 03:17:26 +00:00
\begin{funcdesc}{execvp}{path, args}
This is like \code{execv(\var{path}, \var{args})} but duplicates
the shell's actions in searching for an executable file in a list of
directories. The directory list is obtained from
1998-03-10 03:17:26 +00:00
\code{environ['PATH']}.
1994-01-02 01:22:07 +00:00
\end{funcdesc}
1998-03-10 03:17:26 +00:00
\begin{funcdesc}{execvpe}{path, args, env}
This is a cross between \function{execve()} and \function{execvp()}.
The directory list is obtained from \code{\var{env}['PATH']}.
1994-01-02 01:22:07 +00:00
\end{funcdesc}
1998-03-10 03:17:26 +00:00
(The functions \code{execv()} and \code{execve()} are not
documented here, since they are implemented by the OS dependent
module. If the OS dependent module doesn't define either of these,
the functions that rely on it will raise an exception. They are
1998-03-10 03:17:26 +00:00
documented in the section on module \module{posix}, together with all
other functions that \module{os} imports from the OS dependent module.)