From sbw@provis.com Tue Jun 10 17:37:05 1997 From: sbw@provis.com (Sue Williams) Date: Tue, 10 Jun 97 11:37:05 CDT Subject: [PYTHON DOC-SIG] contributing documentation Message-ID: <9706101637.AA21233@puce.provis.com> I hate to ask Questions With Answers Already Published In Some Obvious Place, but after spending a couple minutes looking I can't find it. Even prior to the cmath thread on the main list, I have noticed calls for contributions of documentation, and have thought that this is one area where I might be able to help out. [However, I looked at the list of undocumented modules and discovered that the only one I have used is commands.py! But, we use it quite a bit and I would be happy to document it.] Is there an example of a properly documented module to work from? I would not like to produce some stuff only to find out that it is not in the preferred format. I assume we're talking about doc strings, internal documentation, and something suitable for the Library Reference? Also, I'm not a LaTex user, is that going to be a problem? I see docs posted with /cstuff{} in them that does not look familiar... (Again, perhaps having a template would be sufficient...) Sorry I'm not being more self-starting, but if there's an example lying around it just makes it easier to steal cycles from my real job to help out... Sue _______________ DOC-SIG - SIG for the Python Documentation Project send messages to: doc-sig@python.org administrivia to: doc-sig-request@python.org _______________ From Fred L. Drake, Jr." References: <9706101637.AA21233@puce.provis.com> Message-ID: <199706101650.MAA08932@weyr.cnri.reston.va.us> Sue Williams writes: > of undocumented modules and discovered that the only one I have used > is commands.py! But, we use it quite a bit and I would be happy to > document it.] Sue, I've never heard of commands.py; documentation must be needed! ;-) There is a template with instructions in Doc/libtemplate.tex; existing documentation can be helpful as well if there's something formatted in a similar way to what you want. You might want to take a look at the comments in Doc/myformat.sty as well, since some of the commands are defined there. Guido has some recommendations on docstrings in the tutorial document, but I don't know how well people have followed those. For standard library modules, perhaps the most important item is the section for the reference manual (though others may disagree). Knowing LaTeX helps, and being able to run LaTeX to check the results is crucial, but you should be able to do it without more than the examples in the Python distribution. Those of us familiar with LaTeX can certainly help out if you get stuck. -Fred -- Fred L. Drake, Jr. fdrake@cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive Reston, VA 20191-5434 _______________ DOC-SIG - SIG for the Python Documentation Project send messages to: doc-sig@python.org administrivia to: doc-sig-request@python.org _______________ From Fredrik Lundh" >Even prior to the cmath thread on the main list, I have noticed calls >for contributions of documentation, and have thought that this is one >area where I might be able to help out Great! >Also, I'm not a LaTex user, is that going to be a problem? I see docs >posted with /cstuff{} in them that does not look familiar... Same here. I'd surely write something if the (perceived) threshold wasn't so large... What about HTML? Does anyone have a decent enough HTML to Python Manual Latex converter? I'd write one myself if I had the time... Cheers /F _______________ DOC-SIG - SIG for the Python Documentation Project send messages to: doc-sig@python.org administrivia to: doc-sig-request@python.org _______________ From amk@magnet.com Tue Jun 10 18:16:00 1997 From: amk@magnet.com (Andrew Kuchling) Date: Tue, 10 Jun 1997 13:16:00 -0400 (EDT) Subject: [DOC-SIG] Re: [PYTHON DOC-SIG] contributing documentation In-Reply-To: <9706101637.AA21233@puce.provis.com> from "Sue Williams" at Jun 10, 97 11:37:05 am Message-ID: <199706101716.NAA25238@lemur.magnet.com> > Is there an example of a properly documented module to work from? I would > not like to produce some stuff only to find out that it is not in the > preferred format. I assume we're talking about doc strings, internal > documentation, and something suitable for the Library Reference? Any or all of the above is fine; don't feel obliged to do all three, though that would be nice. (What's internal documentation? Adding comments? Probably not a high priority for that module...) > Also, I'm not a LaTex user, is that going to be a problem? I see docs > posted with /cstuff{} in them that does not look familiar... > (Again, perhaps having a template would be sufficient...) libsocket.tex is very big and uses most of the available macros; for a simple module like command.py, a simple template like libdbm.tex is probably best. If you can't do LaTeX, it's still useful to just write it as a plain ASCII file, and have someone else like me add the LaTeX formatting--it's much easier to produce the formatting than it is to write the actual text! 30-second LaTeX introduction: macros are preceded by \, and may take zero or more parameters which are inside { }. There are lots of different predefined macros: \var{} is for parameter (=variable) names, \code{} is for Python code. There are also more complex environments, which are called by \begin{environment-name} ...stuff \end{environment-name}. There are some notes on the LaTeX macros available at http://people.magnet.com/~amk/sigs/pipermail/1997q2.doc-sig/61beb98e93ef.html Here's a simplified sample function, open() from libdbm.tex: \begin{funcdesc}{open}{filename\, mode} Open a dbm database and return a dbm object. The \var{filename} argument is the name of the database file (without the \file{.dir} or \file{.pag} extensions). The optional \var{mode} argument is the \UNIX{} mode of the file, used only when the database has to be created. It defaults to octal \code{0666}. \end{funcdesc} You could just copy the above, change the function name and parameters, and replace the text. Andrew Kuchling amk@magnet.com http://people.magnet.com/%7Eamk/ _______________ DOC-SIG - SIG for the Python Documentation Project send messages to: doc-sig@python.org administrivia to: doc-sig-request@python.org _______________ From amk@magnet.com Tue Jun 10 18:46:52 1997 From: amk@magnet.com (Andrew Kuchling) Date: Tue, 10 Jun 1997 13:46:52 -0400 (EDT) Subject: [DOC-SIG] Re: [PYTHON DOC-SIG] contributing documentation In-Reply-To: <9706101705.AA26571@arnold.image.ivab.se> from "Fredrik Lundh" at Jun 10, 97 07:12:10 pm Message-ID: <199706101746.NAA26687@lemur.magnet.com> > What about HTML? Does anyone have a decent enough HTML to > Python Manual Latex converter? I'd write one myself if I had the > time... There is a program called html2latex, but I've never used it. There have been discussions in the past about changing markup formats for the documentation--see the doc-sig archives--but inertia has kept us with LaTeX. IMHO it would be good to define an SGML or XML DTD similar to the existing LaTeX macros, and then use Mike Fletcher's XML parser (or some other parser) to produce various output formats. But that's certainly not going to happen for 1.5. Andrew Kuchling amk@magnet.com http://people.magnet.com/%7Eamk/ _______________ DOC-SIG - SIG for the Python Documentation Project send messages to: doc-sig@python.org administrivia to: doc-sig-request@python.org _______________ From lemburg@uni-duesseldorf.de Tue Jun 10 20:04:03 1997 From: lemburg@uni-duesseldorf.de (M.-A. Lemburg) Date: Tue, 10 Jun 1997 21:04:03 +0200 Subject: [DOC-SIG] contributing documentation References: <199706101746.NAA26687@lemur.magnet.com> Message-ID: <339DA522.7760B5B6@uni-duesseldorf.de> Andrew Kuchling wrote: > > > What about HTML? Does anyone have a decent enough HTML to > > Python Manual Latex converter? I'd write one myself if I had the > > time... > > There is a program called html2latex, but I've never used it. > > There have been discussions in the past about changing markup > formats for the documentation--see the doc-sig archives--but inertia > has kept us with LaTeX. IMHO it would be good to define an SGML or > XML DTD similar to the existing LaTeX macros, and then use Mike > Fletcher's XML parser (or some other parser) to produce various output > formats. But that's certainly not going to happen for 1.5. > I think writing documentation should be as easy as possible, so why not use a word-processor like Word, define some formats (with special names that match those in Latex) and have the exported RTF-file converted into Latex. That should be possible (though I don't know enough about RTF myself to write a converter: the wording of the format names is definetly included in RTF-files). -- Marc-Andre Lemburg http://starship.skyport.net/~lemburg -------------------------------------------------------------- _______________ DOC-SIG - SIG for the Python Documentation Project send messages to: doc-sig@python.org administrivia to: doc-sig-request@python.org _______________ From lemburg@uni-duesseldorf.de Tue Jun 10 20:53:07 1997 From: lemburg@uni-duesseldorf.de (M.-A. Lemburg) Date: Tue, 10 Jun 1997 21:53:07 +0200 Subject: [DOC-SIG] contributing documentation References: <199706101746.NAA26687@lemur.magnet.com> <339DA522.7760B5B6@uni-duesseldorf.de> Message-ID: <339DB0A3.2A083444@uni-duesseldorf.de> Pages about converters to and from RTF, HTML, Latex, etc...: http://union.ncsa.uiuc.edu/HyperNews/get/www/html/converters.html http://warum.uni-mannheim.de/packages/WWW/www/converters/rtf/RTF/ http://www.kfa-juelich.de/isr/1/texconv.html Maybe these are of interest to you. -- Marc-Andre Lemburg http://starship.skyport.net/~lemburg -------------------------------------------------------------- _______________ DOC-SIG - SIG for the Python Documentation Project send messages to: doc-sig@python.org administrivia to: doc-sig-request@python.org _______________ From x-aes@telelogic.se Wed Jun 11 07:36:31 1997 From: x-aes@telelogic.se (Andy Eskilsson) Date: 11 Jun 1997 08:36:31 +0200 Subject: [DOC-SIG] Re: [PYTHON DOC-SIG] contributing documentation In-Reply-To: Fredrik Lundh's message of Tue, 10 Jun 1997 19:12:10 +0200 References: Message-ID: / Fredrik Lundh wrote: | | What about HTML? Does anyone have a decent enough HTML to | Python Manual Latex converter? I'd write one myself if I had the | time... It struck me.. I was messing around with Slackwares (linux distrubution) (La)TeX package, and there were included a proggie that converted from html to LaTeX.. Dunno how good/bad it is, but can check it out if someone wants more info. /Andy _______________ DOC-SIG - SIG for the Python Documentation Project send messages to: doc-sig@python.org administrivia to: doc-sig-request@python.org _______________ From x-aes@telelogic.se Wed Jun 11 07:36:31 1997 From: x-aes@telelogic.se (Andy Eskilsson) Date: 11 Jun 1997 08:36:31 +0200 Subject: [DOC-SIG] Re: [PYTHON DOC-SIG] contributing documentation In-Reply-To: Fredrik Lundh's message of Tue, 10 Jun 1997 19:12:10 +0200 References: Message-ID: / Fredrik Lundh wrote: | | What about HTML? Does anyone have a decent enough HTML to | Python Manual Latex converter? I'd write one myself if I had the | time... It struck me.. I was messing around with Slackwares (linux distrubution) (La)TeX package, and there were included a proggie that converted from html to LaTeX.. Dunno how good/bad it is, but can check it out if someone wants more info. /Andy _______________ DOC-SIG - SIG for the Python Documentation Project send messages to: doc-sig@python.org administrivia to: doc-sig-request@python.org _______________ From sbw@provis.com Tue Jun 10 21:34:35 1997 From: sbw@provis.com (Sue Williams) Date: Tue, 10 Jun 97 15:34:35 CDT Subject: [DOC-SIG] Re: [PYTHON DOC-SIG] contributing documentation Message-ID: <9706102034.AA21926@puce.provis.com> OK, I documented commands.py. (Thanks for the pointer to Doc/libtemplate.tex. It was very helpful.) Spent the better part of the afternoon trying to duplicate what I was sure was a buffer limitation only it turns out that its one of my own modules that has that limitation, not commands... (Hmm. Well, whatever.) I do not have access to laTex here (at least I don't think I do). Hopefully this parses. There is only one thing I did (intentionally) that may be suspicious--can you put macros inside quoted strings? This file contains a line: Return the output of "ls -ld \var{file}" as a string ... I don't know if that's legal. So: I've got a libcommands.tex file here, as well as some diffs of commands.py to add doc strings (one for the module, a one-liner for each of three functions). sue libcommands.tex: ------------------------------- \section{Standard module \sectcode{commands}} % If implemented in Python \stmodindex{commands} The \code{commands} module contains wrapper functions for \code{os.popen()} which take a system command as a string and return any output generated by the command, and optionally, the exit status. The \code{commands} module is only usable on systems which support \code{popen()} (currently \UNIX{}). The \code{commands} module defines the following functions: \renewcommand{\indexsubitem}{(in module commands)} \begin{funcdesc}{getstatusoutput}{cmd} Execute the string \var{cmd} in a shell with \code{os.popen()} and return a 2-tuple (status, output). \var{cmd} is actually run as "{ cmd ; } 2>$1", so that the returned output will contain output or error messages. A trailing newline is stripped from the output. The exit status for the command can be interpreted according to the rules for the \C{} function \code{wait()}. \end{funcdesc} \begin{funcdesc}{getoutput}{cmd} Like \code{getstatusoutput()}, except the exit status is ignored and the return value is a string containing the command's output. \end{funcdesc} \begin{funcdesc}{getstatus}{file} Return the output of "ls -ld \var{file}" as a string. This function uses the \code{getoutput()} function, and properly escapes backslashes and dollar signs in the argument. \end{funcdesc} Example: \begin{verbatim} >>> import commands >>> commands.getstatusoutput('ls /bin/ls') (0, '/bin/ls') >>> commands.getstatusoutput('cat /bin/junk') (256, 'cat: /bin/junk: No such file or directory') >>> commands.getstatusoutput('/bin/junk') (256, 'sh: /bin/junk: not found') >>> commands.getoutput('ls /bin/ls') '/bin/ls' >>> commands.getstatus('/bin/ls') '-rwxr-xr-x 1 root 13352 Oct 14 1994 /bin/ls' \end{verbatim} ------------------------- commands.py diffs: ------------------------- *** commands.py Tue Jun 10 15:17:01 1997 --- commands.py.orig Wed Jan 4 13:20:00 1995 *************** *** 1,24 **** - """Execute shell commands via os.popen() and return status, output. - - Interface summary: - - import commands - - outtext = commands.getoutput(cmd) - (exitstatus, outtext) = commands.getstatusoutput(cmd) - outtext = commands.getstatus(file) # returns output of "ls -ld file" - - A trailing newline is removed from the output string. - - Encapsulates the basic operation: - - pipe = os.popen('{ ' + cmd + '; } 2>&1', 'r') - text = pipe.read() - sts = pipe.close() - - [Note: it would be nice to add functions to interpret the exit status.] - """ - # Module 'commands' # # Various tools for executing commands and looking at their output and status.--- 1,3 ---- *************** *** 29,35 **** # Get 'ls -l' status for an object into a string # def getstatus(file): - """Return output of "ls -ld " in a string""" return getoutput('ls -ld' + mkarg(file)) --- 8,13 ---- *************** *** 38,44 **** # Assume the command will work with '{ ... ; } 2>&1' around it.. # def getoutput(cmd): - """Return output (stdout or stderr) of executing cmd in a shell""" return getstatusoutput(cmd)[1] --- 16,21 ---- *************** *** 46,52 **** # Returns a pair (sts, output) # def getstatusoutput(cmd): - """Return (status, output) of executing cmd in a shell""" import os pipe = os.popen('{ ' + cmd + '; } 2>&1', 'r') text = pipe.read() --- 23,28 ---- _______________ DOC-SIG - SIG for the Python Documentation Project send messages to: doc-sig@python.org administrivia to: doc-sig-request@python.org _______________ From gerco@cs.vu.nl Wed Jun 11 20:46:53 1997 From: gerco@cs.vu.nl (Gerco Ballintijn) Date: Wed, 11 Jun 1997 21:46:53 +0200 (MET DST) Subject: [DOC-SIG] Tutorial Message-ID: Hi, I was wondering what the plans were concerning the tutorial. Will it contain a new chapter 'New in Release 1.5' or is there a rework coming along? I think an up to date tutorial is beneficial to new Python programmers. The tutorial is less important to seasoned veteran programmers, but to new programmers it can be an important stepping stone. I found it a usefull introduction to the source code and the examples around. I would be willing to contribute in this area. Gerco. ----------------------------------v------------------------------------ G.C. Ballintijn | Oh, Fortuna mailto:gerco@cs.vu.nl | Velut luna http://www.cs.vu.nl/~gerco/ | Statu variabilis..... _______________ DOC-SIG - SIG for the Python Documentation Project send messages to: doc-sig@python.org administrivia to: doc-sig-request@python.org _______________ From da@maigret.cog.brown.edu Wed Jun 11 21:22:05 1997 From: da@maigret.cog.brown.edu (David Ascher) Date: Wed, 11 Jun 1997 16:22:05 -0400 (EDT) Subject: [DOC-SIG] Tutorial In-Reply-To: Message-ID: On Wed, 11 Jun 1997, Gerco Ballintijn wrote: > I was wondering what the plans were concerning the tutorial. > Will it contain a new chapter 'New in Release 1.5' or is > there a rework coming along? I think an up to date tutorial > is beneficial to new Python programmers. The tutorial is > less important to seasoned veteran programmers, but to new > programmers it can be an important stepping stone. I found > it a usefull introduction to the source code and the examples > around. I would be willing to contribute in this area. As Guido is away, I'll answer w/ my understanding. The tutorial is badly in need of a complete overhaul. It's on Guido's TODO list, but as we all know, that's a big list. I think that the original tutorial is excellent -- it is the single thing which decided me to *really* try Python, and I'm glad I did. If you are willing to try an overhaul, I'd say go right ahead -- but be aware that Guido (et al.) will probably want to be quite tough editors with whatever you come up with -- rightly so, I think, since the document has high visibility. But this is not at all meant to discourage an effort -- anyone who volunteers to help with any aspect of the doc will be encouraged, and anyone who delivers good doc will be heralded high and wide! (maybe we should have a "Python contributor of the month" award =). --da _______________ DOC-SIG - SIG for the Python Documentation Project send messages to: doc-sig@python.org administrivia to: doc-sig-request@python.org _______________ From amk@magnet.com Wed Jun 11 21:59:33 1997 From: amk@magnet.com (Andrew Kuchling) Date: Wed, 11 Jun 1997 16:59:33 -0400 (EDT) Subject: [DOC-SIG] Tutorial In-Reply-To: from "Gerco Ballintijn" at Jun 11, 97 09:46:53 pm Message-ID: <199706112059.QAA17461@lemur.magnet.com> > I was wondering what the plans were concerning the tutorial. > Will it contain a new chapter 'New in Release 1.5' or is > there a rework coming along? I think an up to date tutorial I'm reworking it quite a bit at the moment, and hope to post a draft sometime this week. (But don't count on that...) The various "New in Release 1.X" sections will be gone, and the relevant bits will have been put in the main body of the text. Skip Montanaro and Konrad Hinsen have suggested more extensive changes to the tutorial's organization, and I'd like to add a chapter about important modules like regex; we'll worry about such potential changes in future drafts... Andrew Kuchling amk@magnet.com http://people.magnet.com/%7Eamk/ _______________ DOC-SIG - SIG for the Python Documentation Project send messages to: doc-sig@python.org administrivia to: doc-sig-request@python.org _______________ From cjr@bound.xs4all.nl Thu Jun 12 00:37:28 1997 From: cjr@bound.xs4all.nl (Case Roole) Date: Thu, 12 Jun 1997 00:37:28 +0100 (WET DST) Subject: [DOC-SIG] Re: [PYTHON DOC-SIG] contributing documentation In-Reply-To: <9706102034.AA21926@puce.provis.com> from "Sue Williams" at Jun 10, 97 03:34:35 pm Message-ID: <199706112337.AAA05449@bound.xs4all.nl> Sue Williams wrote: > OK, I documented commands.py. (Thanks for the pointer to Doc/libtemplate.tex. > It was very helpful.) (snip) > I do not have access to laTex here (at least I don't think I do). > Hopefully this parses. There is only one thing I did (intentionally) > that may be suspicious--can you put macros inside quoted strings? No problem: LaTeX doesn't know "strings", only quotes. Well, it parsed but for one phrase: '2>$1'. First, $ delimits the "math environment" in LaTeX. You can show a $ by backslashing it. Second, > is turned into an inverted exclamation mark *outside* the math environement, but you can show it by $>$. Thus the wanted phrase is produced by: 2$>$\$1. > So: I've got a libcommands.tex file here, as well as some diffs of > commands.py to add doc strings (one for the module, a one-liner for > each of three functions). I read the document and, loo, I'll stop struggling with os.popen from now on. Below I have attached the original file with the above change. Note that I placed this file my in python ./Doc directory and used a reduced version of lib.tex to compile it. To get the LaTeX code actually to compile you must use a documentclass wrapper that includes the macros. I used: \documentstyle[twoside,11pt,myformat]{report} \begin{document} \pagenumbering{roman} \input{libcommand} \end{document} cjr -- Case Roole ------ libcommand.tex -- cut here -------------------------------------- \section{Standard module \sectcode{commands}} % If implemented in Python \stmodindex{commands} The \code{commands} module contains wrapper functions for \code{os.popen()} which take a system command as a string and return any output generated by the command, and optionally, the exit status. The \code{commands} module is only usable on systems which support \code{popen()} (currently \UNIX{}). The \code{commands} module defines the following functions: \renewcommand{\indexsubitem}{(in module commands)} \begin{funcdesc}{getstatusoutput}{cmd} Execute the string \var{cmd} in a shell with \code{os.popen()} and return a 2-tuple (status, output). \var{cmd} is actually run as "{ cmd ; } 2$>$\$1", so that the returned output will contain output or error messages. A trailing newline is stripped from the output. The exit status for the command can be interpreted according to the rules for the \C{} function \code{wait()}. \end{funcdesc} \begin{funcdesc}{getoutput}{cmd} Like \code{getstatusoutput()}, except the exit status is ignored and the return value is a string containing the command's output. \end{funcdesc} \begin{funcdesc}{getstatus}{file} Return the output of "ls -ld \var{file}" as a string. This function uses the \code{getoutput()} function, and properly escapes backslashes and dollar signs in the argument. \end{funcdesc} Example: \begin{verbatim} >>> import commands >>> commands.getstatusoutput('ls /bin/ls') (0, '/bin/ls') >>> commands.getstatusoutput('cat /bin/junk') (256, 'cat: /bin/junk: No such file or directory') >>> commands.getstatusoutput('/bin/junk') (256, 'sh: /bin/junk: not found') >>> commands.getoutput('ls /bin/ls') '/bin/ls' >>> commands.getstatus('/bin/ls') '-rwxr-xr-x 1 root 13352 Oct 14 1994 /bin/ls' \end{verbatim} _______________ DOC-SIG - SIG for the Python Documentation Project send messages to: doc-sig@python.org administrivia to: doc-sig-request@python.org _______________ From Fred L. Drake, Jr." References: <9706102034.AA21926@puce.provis.com> Message-ID: <199706121813.OAA14719@weyr.cnri.reston.va.us> --j5bEMfKP/O Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sue, I've added libcommands.tex and your patches to the Python development tree; they'll be in the next distribution. I did have to make a couple of minor changes to the LaTeX, but they'd be hard to have done without knowing LaTeX yourself, and I'm happy to make them. (It's a lot easier checking someone else's documentation than starting from scratch as well!) I've attached the finished libcommands.tex as it appears in the sources. Thanks! -Fred -- Fred L. Drake, Jr. fdrake@cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive Reston, VA 20191-5434 --j5bEMfKP/O Content-Type: text/plain Content-Description: final libcommands.te Content-Disposition: inline; filename="libcommands.tex" Content-Transfer-Encoding: 7bit \section{Standard module \sectcode{commands}} % If implemented in Python \stmodindex{commands} The \code{commands} module contains wrapper functions for \code{os.popen()} which take a system command as a string and return any output generated by the command, and optionally, the exit status. The \code{commands} module is only usable on systems which support \code{popen()} (currently \UNIX{}). The \code{commands} module defines the following functions: \renewcommand{\indexsubitem}{(in module commands)} \begin{funcdesc}{getstatusoutput}{cmd} Execute the string \var{cmd} in a shell with \code{os.popen()} and return a 2-tuple (status, output). \var{cmd} is actually run as \samp{\{\ cmd \} ; 2$>$\$1}, so that the returned output will contain output or error messages. A trailing newline is stripped from the output. The exit status for the command can be interpreted according to the rules for the \C{} function \code{wait()}. \end{funcdesc} \begin{funcdesc}{getoutput}{cmd} Like \code{getstatusoutput()}, except the exit status is ignored and the return value is a string containing the command's output. \end{funcdesc} \begin{funcdesc}{getstatus}{file} Return the output of \samp{ls -ld \var{file}} as a string. This function uses the \code{getoutput()} function, and properly escapes backslashes and dollar signs in the argument. \end{funcdesc} Example: \begin{verbatim} >>> import commands >>> commands.getstatusoutput('ls /bin/ls') (0, '/bin/ls') >>> commands.getstatusoutput('cat /bin/junk') (256, 'cat: /bin/junk: No such file or directory') >>> commands.getstatusoutput('/bin/junk') (256, 'sh: /bin/junk: not found') >>> commands.getoutput('ls /bin/ls') '/bin/ls' >>> commands.getstatus('/bin/ls') '-rwxr-xr-x 1 root 13352 Oct 14 1994 /bin/ls' \end{verbatim} --j5bEMfKP/O-- _______________ DOC-SIG - SIG for the Python Documentation Project send messages to: doc-sig@python.org administrivia to: doc-sig-request@python.org _______________