Guido van Rossum | 5fdeeea | 1994-01-02 01:22:07 +0000 | [diff] [blame] | 1 | \section{Standard Module \sectcode{os}} |
| 2 | |
| 3 | \stmodindex{os} |
| 4 | This module provides a more portable way of using operating system |
| 5 | (OS) dependent functionality than importing an OS dependent built-in |
| 6 | module like \code{posix}. |
| 7 | |
| 8 | When the optional built-in module \code{posix} is available, this |
| 9 | module exports the same functions and data as \code{posix}; otherwise, |
| 10 | it searches for an OS dependent built-in module like \code{mac} and |
| 11 | exports the same functions and data as found there. The design of all |
Guido van Rossum | 6bb1adc | 1995-03-13 10:03:32 +0000 | [diff] [blame] | 12 | Python's built-in OS dependent modules is such that as long as the same |
Guido van Rossum | 5fdeeea | 1994-01-02 01:22:07 +0000 | [diff] [blame] | 13 | functionality is available, it uses the same interface; e.g., the |
| 14 | function \code{os.stat(\var{file})} returns stat info about a \var{file} in a |
| 15 | format compatible with the POSIX interface. |
| 16 | |
| 17 | Extensions peculiar to a particular OS are also available through the |
| 18 | \code{os} module, but using them is of course a threat to portability! |
| 19 | |
| 20 | Note that after the first time \code{os} is imported, there is \emph{no} |
| 21 | performance penalty in using functions from \code{os} instead of |
| 22 | directly from the OS dependent built-in module, so there should be |
| 23 | \emph{no} reason not to use \code{os}! |
| 24 | |
| 25 | In addition to whatever the correct OS dependent module exports, the |
| 26 | following variables and functions are always exported by \code{os}: |
| 27 | |
| 28 | \renewcommand{\indexsubitem}{(in module os)} |
Guido van Rossum | 470be14 | 1995-03-17 16:07:09 +0000 | [diff] [blame] | 29 | |
Guido van Rossum | 5fdeeea | 1994-01-02 01:22:07 +0000 | [diff] [blame] | 30 | \begin{datadesc}{name} |
Guido van Rossum | 470be14 | 1995-03-17 16:07:09 +0000 | [diff] [blame] | 31 | The name of the OS dependent module imported. The following names |
| 32 | have currently been registered: \code{'posix'}, \code{'nt'}, |
| 33 | \code{'dos'}, \code{'mac'}. |
Guido van Rossum | 5fdeeea | 1994-01-02 01:22:07 +0000 | [diff] [blame] | 34 | \end{datadesc} |
| 35 | |
| 36 | \begin{datadesc}{path} |
| 37 | The corresponding OS dependent standard module for pathname |
| 38 | operations, e.g., \code{posixpath} or \code{macpath}. Thus, (given |
| 39 | the proper imports), \code{os.path.split(\var{file})} is equivalent to but |
| 40 | more portable than \code{posixpath.split(\var{file})}. |
| 41 | \end{datadesc} |
| 42 | |
| 43 | \begin{datadesc}{curdir} |
| 44 | The constant string used by the OS to refer to the current directory, |
| 45 | e.g. \code{'.'} for POSIX or \code{':'} for the Mac. |
| 46 | \end{datadesc} |
| 47 | |
| 48 | \begin{datadesc}{pardir} |
| 49 | The constant string used by the OS to refer to the parent directory, |
| 50 | e.g. \code{'..'} for POSIX or \code{'::'} for the Mac. |
| 51 | \end{datadesc} |
| 52 | |
| 53 | \begin{datadesc}{sep} |
Guido van Rossum | 470be14 | 1995-03-17 16:07:09 +0000 | [diff] [blame] | 54 | The character used by the OS to separate pathname components, e.g.\ |
Guido van Rossum | 5fdeeea | 1994-01-02 01:22:07 +0000 | [diff] [blame] | 55 | \code{'/'} for POSIX or \code{':'} for the Mac. Note that knowing this |
| 56 | is not sufficient to be able to parse or concatenate pathnames---better |
| 57 | use \code{os.path.split()} and \code{os.path.join()}---but it is |
| 58 | occasionally useful. |
| 59 | \end{datadesc} |
| 60 | |
Guido van Rossum | 470be14 | 1995-03-17 16:07:09 +0000 | [diff] [blame] | 61 | \begin{datadesc}{pathsep} |
| 62 | The character conventionally used by the OS to separate search patch |
| 63 | components (as in \code{\$PATH}), e.g.\ \code{':'} for POSIX or |
| 64 | \code{';'} for MS-DOS. |
| 65 | \end{datadesc} |
| 66 | |
| 67 | \begin{datadesc}{defpath} |
| 68 | The default search path used by \code{os.exec*p*()} if the environment |
| 69 | doesn't have a \code{'PATH'} key. |
| 70 | \end{datadesc} |
| 71 | |
Guido van Rossum | 5fdeeea | 1994-01-02 01:22:07 +0000 | [diff] [blame] | 72 | \begin{funcdesc}{execl}{path\, arg0\, arg1\, ...} |
Guido van Rossum | 470be14 | 1995-03-17 16:07:09 +0000 | [diff] [blame] | 73 | This is equivalent to |
| 74 | \code{os.execv(\var{path}, (\var{arg0}, \var{arg1}, ...))}. |
Guido van Rossum | 5fdeeea | 1994-01-02 01:22:07 +0000 | [diff] [blame] | 75 | \end{funcdesc} |
| 76 | |
| 77 | \begin{funcdesc}{execle}{path\, arg0\, arg1\, ...\, env} |
Guido van Rossum | 470be14 | 1995-03-17 16:07:09 +0000 | [diff] [blame] | 78 | This is equivalent to |
| 79 | \code{os.execve(\var{path}, (\var{arg0}, \var{arg1}, ...), \var{env})}. |
Guido van Rossum | 5fdeeea | 1994-01-02 01:22:07 +0000 | [diff] [blame] | 80 | \end{funcdesc} |
| 81 | |
| 82 | \begin{funcdesc}{execlp}{path\, arg0\, arg1\, ...} |
Guido van Rossum | 470be14 | 1995-03-17 16:07:09 +0000 | [diff] [blame] | 83 | This is equivalent to |
| 84 | \code{os.execvp(\var{path}, (\var{arg0}, \var{arg1}, ...))}. |
Guido van Rossum | 5fdeeea | 1994-01-02 01:22:07 +0000 | [diff] [blame] | 85 | \end{funcdesc} |
| 86 | |
Guido van Rossum | 470be14 | 1995-03-17 16:07:09 +0000 | [diff] [blame] | 87 | \begin{funcdesc}{execvp}{path\, args} |
| 88 | This is like \code{os.execv(\var{path}, \var{args})} but duplicates |
| 89 | the shell's actions in searching for an executable file in a list of |
| 90 | directories. The directory list is obtained from |
| 91 | \code{os.environ['PATH']}. |
Guido van Rossum | 5fdeeea | 1994-01-02 01:22:07 +0000 | [diff] [blame] | 92 | \end{funcdesc} |
Guido van Rossum | 470be14 | 1995-03-17 16:07:09 +0000 | [diff] [blame] | 93 | |
| 94 | \begin{funcdesc}{execvpe}{path\, args\, env} |
| 95 | This is a cross between \code{os.execve()} and \code{os.execvp()}. |
| 96 | The directory list is obtained from \code{\var{env}['PATH']}. |
| 97 | \end{funcdesc} |
| 98 | |
| 99 | (The functions \code{os.execv()} and \code{execve()} are not |
| 100 | documented here, since they are implemented by the OS dependent |
| 101 | module. If the OS dependent module doesn't define either of these, |
| 102 | the functions that rely on it will raise an exception. They are |
| 103 | documented in the section on module \code{posix}, together with all |
| 104 | other functions that \code{os} imports from the OS dependent module.) |