home *** CD-ROM | disk | FTP | other *** search
/ The Datafile PD-CD 5 / DATAFILE_PDCD5.iso / utilities / p / python / pyhtmldoc / o / os < prev    next >
Encoding:
Text File  |  1996-11-14  |  5.0 KB  |  94 lines
  1. <TITLE>os -- Python library reference</TITLE>
  2. Next: <A HREF="../t/time" TYPE="Next">time</A>  
  3. Prev: <A HREF="../g/generic_operating_system_services" TYPE="Prev">Generic Operating System Services</A>  
  4. Up: <A HREF="../g/generic_operating_system_services" TYPE="Up">Generic Operating System Services</A>  
  5. Top: <A HREF="../t/top" TYPE="Top">Top</A>  
  6. <H1>6.1. Standard Module <CODE>os</CODE></H1>
  7. This module provides a more portable way of using operating system
  8. (OS) dependent functionality than importing an OS dependent built-in
  9. module like <CODE>posix</CODE>.
  10. <P>
  11. When the optional built-in module <CODE>posix</CODE> is available, this
  12. module exports the same functions and data as <CODE>posix</CODE>; otherwise,
  13. it searches for an OS dependent built-in module like <CODE>mac</CODE> and
  14. exports the same functions and data as found there.  The design of all
  15. Python's built-in OS dependent modules is such that as long as the same
  16. functionality is available, it uses the same interface; e.g., the
  17. function <CODE>os.stat(<VAR>file</VAR>)</CODE> returns stat info about a <VAR>file</VAR> in a
  18. format compatible with the POSIX interface.
  19. <P>
  20. Extensions peculiar to a particular OS are also available through the
  21. <CODE>os</CODE> module, but using them is of course a threat to portability!
  22. <P>
  23. Note that after the first time <CODE>os</CODE> is imported, there is <I>no</I>
  24. performance penalty in using functions from <CODE>os</CODE> instead of
  25. directly from the OS dependent built-in module, so there should be
  26. <I>no</I> reason not to use <CODE>os</CODE>!
  27. <P>
  28. In addition to whatever the correct OS dependent module exports, the
  29. following variables and functions are always exported by <CODE>os</CODE>:
  30. <P>
  31. <DL><DT><B>name</B> -- data of module os<DD>
  32. The name of the OS dependent module imported.  The following names
  33. have currently been registered: <CODE>'posix'</CODE>, <CODE>'nt'</CODE>,
  34. <CODE>'dos'</CODE>, <CODE>'mac'</CODE>.
  35. </DL>
  36. <DL><DT><B>path</B> -- data of module os<DD>
  37. The corresponding OS dependent standard module for pathname
  38. operations, e.g., <CODE>posixpath</CODE> or <CODE>macpath</CODE>.  Thus, (given
  39. the proper imports), <CODE>os.path.split(<VAR>file</VAR>)</CODE> is equivalent to but
  40. more portable than <CODE>posixpath.split(<VAR>file</VAR>)</CODE>.
  41. </DL>
  42. <DL><DT><B>curdir</B> -- data of module os<DD>
  43. The constant string used by the OS to refer to the current directory,
  44. e.g. <CODE>'.'</CODE> for POSIX or <CODE>':'</CODE> for the Mac.
  45. </DL>
  46. <DL><DT><B>pardir</B> -- data of module os<DD>
  47. The constant string used by the OS to refer to the parent directory,
  48. e.g. <CODE>'..'</CODE> for POSIX or <CODE>'::'</CODE> for the Mac.
  49. </DL>
  50. <DL><DT><B>sep</B> -- data of module os<DD>
  51. The character used by the OS to separate pathname components, e.g.
  52. <CODE>'/'</CODE> for POSIX or <CODE>':'</CODE> for the Mac.  Note that knowing this
  53. is not sufficient to be able to parse or concatenate pathnames---better
  54. use <CODE>os.path.split()</CODE> and <CODE>os.path.join()</CODE>---but it is
  55. occasionally useful.
  56. </DL>
  57. <DL><DT><B>pathsep</B> -- data of module os<DD>
  58. The character conventionally used by the OS to separate search patch
  59. components (as in <CODE>$PATH</CODE>), e.g. <CODE>':'</CODE> for POSIX or
  60. <CODE>';'</CODE> for MS-DOS.
  61. </DL>
  62. <DL><DT><B>defpath</B> -- data of module os<DD>
  63. The default search path used by <CODE>os.exec*p*()</CODE> if the environment
  64. doesn't have a <CODE>'PATH'</CODE> key.
  65. </DL>
  66. <DL><DT><B>execl</B> (<VAR>path</VAR>, <VAR>arg0</VAR>, <VAR>arg1</VAR>, ...) -- function of module os<DD>
  67. This is equivalent to
  68. <CODE>os.execv(<VAR>path</VAR>, (<VAR>arg0</VAR>, <VAR>arg1</VAR>, ...))</CODE>.
  69. </DL>
  70. <DL><DT><B>execle</B> (<VAR>path</VAR>, <VAR>arg0</VAR>, <VAR>arg1</VAR>, ..., <VAR>env</VAR>) -- function of module os<DD>
  71. This is equivalent to
  72. <CODE>os.execve(<VAR>path</VAR>, (<VAR>arg0</VAR>, <VAR>arg1</VAR>, ...), <VAR>env</VAR>)</CODE>.
  73. </DL>
  74. <DL><DT><B>execlp</B> (<VAR>path</VAR>, <VAR>arg0</VAR>, <VAR>arg1</VAR>, ...) -- function of module os<DD>
  75. This is equivalent to
  76. <CODE>os.execvp(<VAR>path</VAR>, (<VAR>arg0</VAR>, <VAR>arg1</VAR>, ...))</CODE>.
  77. </DL>
  78. <DL><DT><B>execvp</B> (<VAR>path</VAR>, <VAR>args</VAR>) -- function of module os<DD>
  79. This is like <CODE>os.execv(<VAR>path</VAR>, <VAR>args</VAR>)</CODE> but duplicates
  80. the shell's actions in searching for an executable file in a list of
  81. directories.  The directory list is obtained from
  82. <CODE>os.environ['PATH']</CODE>.
  83. </DL>
  84. <DL><DT><B>execvpe</B> (<VAR>path</VAR>, <VAR>args</VAR>, <VAR>env</VAR>) -- function of module os<DD>
  85. This is a cross between <CODE>os.execve()</CODE> and <CODE>os.execvp()</CODE>.
  86. The directory list is obtained from <CODE><VAR>env</VAR>['PATH']</CODE>.
  87. </DL>
  88. (The functions <CODE>os.execv()</CODE> and <CODE>execve()</CODE> are not
  89. documented here, since they are implemented by the OS dependent
  90. module.  If the OS dependent module doesn't define either of these,
  91. the functions that rely on it will raise an exception.  They are
  92. documented in the section on module <CODE>posix</CODE>, together with all
  93. other functions that <CODE>os</CODE> imports from the OS dependent module.)
  94.