mirrors/cpython
1
0
Fork 0
mirror of https://github.com/python/cpython.git synced 2025-11-02 11:08:57 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 15

Logical markup. small nits.

Browse source
This commit is contained in:
Fred Drake 1998-03-10 03:17:26 +00:00
parent 5bfac8d7fd
commit c4f15af7de
2 changed files with 70 additions and 72 deletions
Download patch file Download diff file Expand all files Collapse all files

71
Doc/lib/libos.tex
View file

@ -1,32 +1,31 @@
\section{Standard Module \sectcode{os}} \section{Standard Module \sectcode{os}}
\label{module-os} \label{module-os}
\stmodindex{os} \stmodindex{os}
This module provides a more portable way of using operating system This module provides a more portable way of using operating system
(OS) dependent functionality than importing an OS dependent built-in (OS) dependent functionality than importing an OS dependent built-in
module like \code{posix}. module like \module{posix}.
When the optional built-in module \code{posix} is available, this When the optional built-in module \module{posix} is available, this
module exports the same functions and data as \code{posix}; otherwise, module exports the same functions and data as \module{posix}; otherwise,
it searches for an OS dependent built-in module like \code{mac} and it searches for an OS dependent built-in module like \module{mac} and
exports the same functions and data as found there. The design of all exports the same functions and data as found there. The design of all
Python's built-in OS dependent modules is such that as long as the same Python's built-in OS dependent modules is such that as long as the same
functionality is available, it uses the same interface; e.g., the functionality is available, it uses the same interface; e.g., the
function \code{os.stat(\var{file})} returns stat info about a \var{file} in a function \code{os.stat(\var{file})} returns stat info about \var{file}
format compatible with the \POSIX{} interface. in a format compatible with the \POSIX{} interface.
Extensions peculiar to a particular OS are also available through the Extensions peculiar to a particular OS are also available through the
\code{os} module, but using them is of course a threat to portability! \module{os} module, but using them is of course a threat to
portability!
Note that after the first time \code{os} is imported, there is \emph{no} Note that after the first time \module{os} is imported, there is
performance penalty in using functions from \code{os} instead of \emph{no} performance penalty in using functions from \module{os}
directly from the OS dependent built-in module, so there should be instead of directly from the OS dependent built-in module, so there
\emph{no} reason not to use \code{os}! should be \emph{no} reason not to use \module{os}!
In addition to whatever the correct OS dependent module exports, the In addition to whatever the correct OS dependent module exports, the
following variables and functions are always exported by \code{os}: following variables and functions are always exported by \module{os}:
\setindexsubitem{(in module os)}
\begin{datadesc}{name} \begin{datadesc}{name}
The name of the OS dependent module imported. The following names The name of the OS dependent module imported. The following names
@ -36,27 +35,27 @@ have currently been registered: \code{'posix'}, \code{'nt'},
\begin{datadesc}{path} \begin{datadesc}{path}
The corresponding OS dependent standard module for pathname The corresponding OS dependent standard module for pathname
operations, e.g., \code{posixpath} or \code{macpath}. Thus, (given operations, e.g., \module{posixpath} or \module{macpath}. Thus, (given
the proper imports), \code{os.path.split(\var{file})} is equivalent to but the proper imports), \code{os.path.split(\var{file})} is equivalent to but
more portable than \code{posixpath.split(\var{file})}. more portable than \code{posixpath.split(\var{file})}.
\end{datadesc} \end{datadesc}
\begin{datadesc}{curdir} \begin{datadesc}{curdir}
The constant string used by the OS to refer to the current directory, The constant string used by the OS to refer to the current directory,
e.g. \code{'.'} for \POSIX{} or \code{':'} for the Mac. e.g. \code{'.'} for \POSIX{} or \code{':'} for the Macintosh.
\end{datadesc} \end{datadesc}
\begin{datadesc}{pardir} \begin{datadesc}{pardir}
The constant string used by the OS to refer to the parent directory, The constant string used by the OS to refer to the parent directory,
e.g. \code{'..'} for \POSIX{} or \code{'::'} for the Mac. e.g. \code{'..'} for \POSIX{} or \code{'::'} for the Macintosh.
\end{datadesc} \end{datadesc}
\begin{datadesc}{sep} \begin{datadesc}{sep}
The character used by the OS to separate pathname components, The character used by the OS to separate pathname components,
e.g. \code{'/'} for \POSIX{} or \code{':'} for the Mac. Note that e.g. \code{'/'} for \POSIX{} or \code{':'} for the Macintosh. Note that
knowing this is not sufficient to be able to parse or concatenate knowing this is not sufficient to be able to parse or concatenate
pathnames --- better use \code{os.path.split()} and pathnames --- better use \function{os.path.split()} and
\code{os.path.join()}---but it is occasionally useful. \function{os.path.join()}---but it is occasionally useful.
\end{datadesc} \end{datadesc}
\begin{datadesc}{altsep} \begin{datadesc}{altsep}
@ -72,40 +71,40 @@ components (as in \code{\$PATH}), e.g.\ \code{':'} for \POSIX{} or
\end{datadesc} \end{datadesc}
\begin{datadesc}{defpath} \begin{datadesc}{defpath}
The default search path used by \code{os.exec*p*()} if the environment The default search path used by \code{exec*p*()} if the environment
doesn't have a \code{'PATH'} key. doesn't have a \code{'PATH'} key.
\end{datadesc} \end{datadesc}
\begin{funcdesc}{execl}{path\, arg0\, arg1\, ...} \begin{funcdesc}{execl}{path, arg0, arg1, ...}
This is equivalent to This is equivalent to
\code{os.execv(\var{path}, (\var{arg0}, \var{arg1}, ...))}. \code{execv(\var{path}, (\var{arg0}, \var{arg1}, ...))}.
\end{funcdesc} \end{funcdesc}
\begin{funcdesc}{execle}{path\, arg0\, arg1\, ...\, env} \begin{funcdesc}{execle}{path, arg0, arg1, ..., env}
This is equivalent to This is equivalent to
\code{os.execve(\var{path}, (\var{arg0}, \var{arg1}, ...), \var{env})}. \code{execve(\var{path}, (\var{arg0}, \var{arg1}, ...), \var{env})}.
\end{funcdesc} \end{funcdesc}
\begin{funcdesc}{execlp}{path\, arg0\, arg1\, ...} \begin{funcdesc}{execlp}{path, arg0, arg1, ...}
This is equivalent to This is equivalent to
\code{os.execvp(\var{path}, (\var{arg0}, \var{arg1}, ...))}. \code{execvp(\var{path}, (\var{arg0}, \var{arg1}, ...))}.
\end{funcdesc} \end{funcdesc}
\begin{funcdesc}{execvp}{path\, args} \begin{funcdesc}{execvp}{path, args}
This is like \code{os.execv(\var{path}, \var{args})} but duplicates 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 the shell's actions in searching for an executable file in a list of
directories. The directory list is obtained from directories. The directory list is obtained from
\code{os.environ['PATH']}. \code{environ['PATH']}.
\end{funcdesc} \end{funcdesc}
\begin{funcdesc}{execvpe}{path\, args\, env} \begin{funcdesc}{execvpe}{path, args, env}
This is a cross between \code{os.execve()} and \code{os.execvp()}. This is a cross between \function{execve()} and \function{execvp()}.
The directory list is obtained from \code{\var{env}['PATH']}. The directory list is obtained from \code{\var{env}['PATH']}.
\end{funcdesc} \end{funcdesc}
(The functions \code{os.execv()} and \code{execve()} are not (The functions \code{execv()} and \code{execve()} are not
documented here, since they are implemented by the OS dependent documented here, since they are implemented by the OS dependent
module. If the OS dependent module doesn't define either of these, module. If the OS dependent module doesn't define either of these,
the functions that rely on it will raise an exception. They are the functions that rely on it will raise an exception. They are
documented in the section on module \code{posix}, together with all documented in the section on module \module{posix}, together with all
other functions that \code{os} imports from the OS dependent module.) other functions that \module{os} imports from the OS dependent module.)

71
Doc/libos.tex
View file

@ -1,32 +1,31 @@
\section{Standard Module \sectcode{os}} \section{Standard Module \sectcode{os}}
\label{module-os} \label{module-os}
\stmodindex{os} \stmodindex{os}
This module provides a more portable way of using operating system This module provides a more portable way of using operating system
(OS) dependent functionality than importing an OS dependent built-in (OS) dependent functionality than importing an OS dependent built-in
module like \code{posix}. module like \module{posix}.
When the optional built-in module \code{posix} is available, this When the optional built-in module \module{posix} is available, this
module exports the same functions and data as \code{posix}; otherwise, module exports the same functions and data as \module{posix}; otherwise,
it searches for an OS dependent built-in module like \code{mac} and it searches for an OS dependent built-in module like \module{mac} and
exports the same functions and data as found there. The design of all exports the same functions and data as found there. The design of all
Python's built-in OS dependent modules is such that as long as the same Python's built-in OS dependent modules is such that as long as the same
functionality is available, it uses the same interface; e.g., the functionality is available, it uses the same interface; e.g., the
function \code{os.stat(\var{file})} returns stat info about a \var{file} in a function \code{os.stat(\var{file})} returns stat info about \var{file}
format compatible with the \POSIX{} interface. in a format compatible with the \POSIX{} interface.
Extensions peculiar to a particular OS are also available through the Extensions peculiar to a particular OS are also available through the
\code{os} module, but using them is of course a threat to portability! \module{os} module, but using them is of course a threat to
portability!
Note that after the first time \code{os} is imported, there is \emph{no} Note that after the first time \module{os} is imported, there is
performance penalty in using functions from \code{os} instead of \emph{no} performance penalty in using functions from \module{os}
directly from the OS dependent built-in module, so there should be instead of directly from the OS dependent built-in module, so there
\emph{no} reason not to use \code{os}! should be \emph{no} reason not to use \module{os}!
In addition to whatever the correct OS dependent module exports, the In addition to whatever the correct OS dependent module exports, the
following variables and functions are always exported by \code{os}: following variables and functions are always exported by \module{os}:
\setindexsubitem{(in module os)}
\begin{datadesc}{name} \begin{datadesc}{name}
The name of the OS dependent module imported. The following names The name of the OS dependent module imported. The following names
@ -36,27 +35,27 @@ have currently been registered: \code{'posix'}, \code{'nt'},
\begin{datadesc}{path} \begin{datadesc}{path}
The corresponding OS dependent standard module for pathname The corresponding OS dependent standard module for pathname
operations, e.g., \code{posixpath} or \code{macpath}. Thus, (given operations, e.g., \module{posixpath} or \module{macpath}. Thus, (given
the proper imports), \code{os.path.split(\var{file})} is equivalent to but the proper imports), \code{os.path.split(\var{file})} is equivalent to but
more portable than \code{posixpath.split(\var{file})}. more portable than \code{posixpath.split(\var{file})}.
\end{datadesc} \end{datadesc}
\begin{datadesc}{curdir} \begin{datadesc}{curdir}
The constant string used by the OS to refer to the current directory, The constant string used by the OS to refer to the current directory,
e.g. \code{'.'} for \POSIX{} or \code{':'} for the Mac. e.g. \code{'.'} for \POSIX{} or \code{':'} for the Macintosh.
\end{datadesc} \end{datadesc}
\begin{datadesc}{pardir} \begin{datadesc}{pardir}
The constant string used by the OS to refer to the parent directory, The constant string used by the OS to refer to the parent directory,
e.g. \code{'..'} for \POSIX{} or \code{'::'} for the Mac. e.g. \code{'..'} for \POSIX{} or \code{'::'} for the Macintosh.
\end{datadesc} \end{datadesc}
\begin{datadesc}{sep} \begin{datadesc}{sep}
The character used by the OS to separate pathname components, The character used by the OS to separate pathname components,
e.g. \code{'/'} for \POSIX{} or \code{':'} for the Mac. Note that e.g. \code{'/'} for \POSIX{} or \code{':'} for the Macintosh. Note that
knowing this is not sufficient to be able to parse or concatenate knowing this is not sufficient to be able to parse or concatenate
pathnames --- better use \code{os.path.split()} and pathnames --- better use \function{os.path.split()} and
\code{os.path.join()}---but it is occasionally useful. \function{os.path.join()}---but it is occasionally useful.
\end{datadesc} \end{datadesc}
\begin{datadesc}{altsep} \begin{datadesc}{altsep}
@ -72,40 +71,40 @@ components (as in \code{\$PATH}), e.g.\ \code{':'} for \POSIX{} or
\end{datadesc} \end{datadesc}
\begin{datadesc}{defpath} \begin{datadesc}{defpath}
The default search path used by \code{os.exec*p*()} if the environment The default search path used by \code{exec*p*()} if the environment
doesn't have a \code{'PATH'} key. doesn't have a \code{'PATH'} key.
\end{datadesc} \end{datadesc}
\begin{funcdesc}{execl}{path\, arg0\, arg1\, ...} \begin{funcdesc}{execl}{path, arg0, arg1, ...}
This is equivalent to This is equivalent to
\code{os.execv(\var{path}, (\var{arg0}, \var{arg1}, ...))}. \code{execv(\var{path}, (\var{arg0}, \var{arg1}, ...))}.
\end{funcdesc} \end{funcdesc}
\begin{funcdesc}{execle}{path\, arg0\, arg1\, ...\, env} \begin{funcdesc}{execle}{path, arg0, arg1, ..., env}
This is equivalent to This is equivalent to
\code{os.execve(\var{path}, (\var{arg0}, \var{arg1}, ...), \var{env})}. \code{execve(\var{path}, (\var{arg0}, \var{arg1}, ...), \var{env})}.
\end{funcdesc} \end{funcdesc}
\begin{funcdesc}{execlp}{path\, arg0\, arg1\, ...} \begin{funcdesc}{execlp}{path, arg0, arg1, ...}
This is equivalent to This is equivalent to
\code{os.execvp(\var{path}, (\var{arg0}, \var{arg1}, ...))}. \code{execvp(\var{path}, (\var{arg0}, \var{arg1}, ...))}.
\end{funcdesc} \end{funcdesc}
\begin{funcdesc}{execvp}{path\, args} \begin{funcdesc}{execvp}{path, args}
This is like \code{os.execv(\var{path}, \var{args})} but duplicates 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 the shell's actions in searching for an executable file in a list of
directories. The directory list is obtained from directories. The directory list is obtained from
\code{os.environ['PATH']}. \code{environ['PATH']}.
\end{funcdesc} \end{funcdesc}
\begin{funcdesc}{execvpe}{path\, args\, env} \begin{funcdesc}{execvpe}{path, args, env}
This is a cross between \code{os.execve()} and \code{os.execvp()}. This is a cross between \function{execve()} and \function{execvp()}.
The directory list is obtained from \code{\var{env}['PATH']}. The directory list is obtained from \code{\var{env}['PATH']}.
\end{funcdesc} \end{funcdesc}
(The functions \code{os.execv()} and \code{execve()} are not (The functions \code{execv()} and \code{execve()} are not
documented here, since they are implemented by the OS dependent documented here, since they are implemented by the OS dependent
module. If the OS dependent module doesn't define either of these, module. If the OS dependent module doesn't define either of these,
the functions that rely on it will raise an exception. They are the functions that rely on it will raise an exception. They are
documented in the section on module \code{posix}, together with all documented in the section on module \module{posix}, together with all
other functions that \code{os} imports from the OS dependent module.) other functions that \module{os} imports from the OS dependent module.)