Executing files

[Cameron Laird]

In article <LNBBLJKPBEHFEDALKOLCOECIHHAA.tim_one at email.msn.com>,
Tim Peters <tim_one at email.msn.com> wrote:
>[Mark W Daley, running a customized Python on something "like" DOS]
>> ...
>> 	- os.system could execute, but the return is whether or not
>> Python executed the command, not whether the command completed
>> successfully.
>
>Since you've customized Python and aren't actually running DOS, it's risky
>to guess, but here goes:
>
>On a non-customized Python running on real DOS, os.system always returns 0
>whenever the argument passed to it runs at all.  That's because command.com
>ignores the exit status of commands *it* runs, returning 0 as its own exit
>status:  Microsoft's implementation of "system" (which Python calls
>directly) builds a command line out of %COMSPEC% and the argument to
>"system", like so:
>
>    %COMSPEC% /c argument_to_system
>
>then spawns a process to run that (note that the source code for Microsoft's
>"system" is available in crt\src\system.c, provided you elected to install
>the C runtime source when you installed MSVC).  Since command.com always
>returns 0, that's what Microsoft's system returns to Python's os.system
>returns to you.
>
>To fix this, you need a better shell, and point the COMSPEC envar at it.
>IIRC, those running NT don't have this problem, because the std shell there
>(cmd.exe) does return the exit status of the command it runs.
			.
			.
			.
Tim, it's also possible to hack an extension to
his 1.5.2 that runs DOS commands directly.  That
is, while I haven't done this with 1.5.2, it's
the kind of thing I used to do with other DOS
applications, and the Python source is plenty
clean enough to make this alternative inviting.

... IF he is in a position to change his Python
language processor.  The original question doesn't
make that clear to me.
-- 

Cameron Laird <claird at NeoSoft.com>
Business:  http://www.Phaseit.net
Personal:  http://starbase.neosoft.com/~claird/home.html