By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,740 Members | 844 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,740 IT Pros & Developers. It's quick & easy.

Batch commands on Windows

P: n/a
So, after reading some messages about os.system, and looking at the popen
stuff and trying it a bit, I still have not found a way to keep a command
window open for several commands (on Windows 2000/XP), while seeing the
normal output in a command window. All I want to do is do what a batch file
does, but I want to actually have functions and associative arrays and all
the other niceties of python.

What's the deal with that? I thought Python started out as a scripting
language. And that seems like the most basic thing that a scripting
language should do. I just want to list the commands, not deal with
capturing the output and redirecting it and all that. It's not just because
I'm too lazy, it's because most of my co-workers don't know Python and I
want to make the transition easier and sell them on it. This seems like an
enormous deficiency. Does anyone know if this can be done?

If not, that's a point for perl, *gasp* : ) Which we _were_ using, but
which I object to for reasons I won't go into.

I have noticed this tendency for really good software to be deficient in
some obvious area. Python has amazed me in many respects, but every so
often I encounter something like this which is pretty disappointing. And
yes I have read PEP 324, but it doesn't seem to make mention anything like
this. Another example is Perforce, which is absolutely outstanding for 99%
of things, but then you encounter some glaring hole. Most software is just
mediocre all around.

thanks,
MB


Jul 18 '05 #1
Share this Question
Share on Google+
12 Replies


P: n/a
> So, after reading some messages about os.system, and looking at the popen
stuff and trying it a bit, I still have not found a way to keep a command
window open for several commands (on Windows 2000/XP), while seeing the
normal output in a command window. All I want to do is do what a batch file
does, but I want to actually have functions and associative arrays and all
the other niceties of python.


Q: "How do I get python to run these other things, and keep the window
open so that I can see their output?"

A: Making sure to run your script with the console version of Python
(python.exe, NOT pythonw.exe):

#insert the body of your script here

raw_input("press enter to continue...");
# or even
#os.system('pause');
Q: "I'm running the non-console version of Python, how do I capture the
output of my scripts so that I can do something with it afterwards?"

A: I'll answer this one tomorrow, it is getting late.

- Josiah
Jul 18 '05 #2

P: n/a
On Fri, 2004-01-23 at 00:56, Moosebumps wrote:
So, after reading some messages about os.system, and looking at the popen
stuff and trying it a bit, I still have not found a way to keep a command
window open for several commands (on Windows 2000/XP), while seeing the
normal output in a command window. All I want to do is do what a batch file
does, but I want to actually have functions and associative arrays and all
the other niceties of python.


1. Open file whatever.py, put this in it:

print "Hello world"

2. Open cmd.exe, navigate to where whatever.py is and type:

whatever.py

What happens?

// m

p.s. It's likely I've misunderstood your question because on the face
of it, as I understand your question, what you're saying is a glaring
hole in Python are aspects of Python I use effortlessly every day.
Jul 18 '05 #3

P: n/a
Moosebumps wrote:
So, after reading some messages about os.system, and looking at the popen
stuff and trying it a bit, I still have not found a way to keep a command
window open for several commands (on Windows 2000/XP), while seeing the
normal output in a command window. All I want to do is do what a batch file
does, but I want to actually have functions and associative arrays and all
the other niceties of python.
Can you give an example of what you mean, in Perl as well as what you hoped
would work in Python? I couldn't quite understand what it is that you're trying
to do.
What's the deal with that? I thought Python started out as a scripting
language. And that seems like the most basic thing that a scripting
language should do.


Dunno, although MS-DOS shell scripting is certainly a small subset of scripting
in general. Maybe with a concrete example somebody will be able to give you a
hand.

-Dave
Jul 18 '05 #4

P: n/a
"Dave Brueck" <da**@pythonapocrypha.com> writes:
Moosebumps wrote:
So, after reading some messages about os.system, and looking at the popen
stuff and trying it a bit, I still have not found a way to keep a command
window open for several commands (on Windows 2000/XP), while seeing the
normal output in a command window. All I want to do is do what a batch file
does, but I want to actually have functions and associative arrays and all
the other niceties of python.


Can you give an example of what you mean, in Perl as well as what you hoped
would work in Python? I couldn't quite understand what it is that you're trying
to do.
What's the deal with that? I thought Python started out as a scripting
language. And that seems like the most basic thing that a scripting
language should do.


Dunno, although MS-DOS shell scripting is certainly a small subset of scripting
in general. Maybe with a concrete example somebody will be able to give you a
hand.

-Dave


I wonder if this is miscommunication over "script" vs "shell window".
This confused me when trying python scripts in MS Windows after using
then in *NIX.

Quite often a script will output to stdout. In *NIX the script is
usually run from a shell, in which case the output goes to the shell
and you can see it. But in Windows there is no automatic shell -- you
have to explicitly tell the script where to put the output. Otherwise
a DOS shell wakes up long enough to complain and then goes away. (At
least that's what I think is happening.)

An alternative is to install cygwin and run scripts from the bash
shell -- you will see output. Even better, install emacs too, then
run scripts from inside am emacs bash shell buffer -- you can then
search, edit, print, etc the output.

Another alternative is to redirect your script output to a file, and
then examine it via notepad or (if linefeeds are screwed up) wordpad.

--
ha************@boeing.com
6-6M31 Knowledge Management
Phone: (425) 342-5601
Jul 18 '05 #5

P: n/a
Harry wrote:
"Dave Brueck" <da**@pythonapocrypha.com> writes:
Moosebumps wrote:
So, after reading some messages about os.system, and looking at the popen
stuff and trying it a bit, I still have not found a way to keep a command
window open for several commands (on Windows 2000/XP), while seeing the
normal output in a command window. All I want to do is do what a batch file does, but I want to actually have functions and associative arrays and all the other niceties of python.


Can you give an example of what you mean, in Perl as well as what you hoped
would work in Python? I couldn't quite understand what it is that you're trying to do.
What's the deal with that? I thought Python started out as a scripting
language. And that seems like the most basic thing that a scripting
language should do.


Dunno, although MS-DOS shell scripting is certainly a small subset of scripting in general. Maybe with a concrete example somebody will be able to give you a hand.

-Dave


I wonder if this is miscommunication over "script" vs "shell window".
This confused me when trying python scripts in MS Windows after using
then in *NIX.


Yeah, I wondered that too, although I thought the OP said this problem didn't
occur with Perl. Maybe I misunderstood the message though.

-Dave
Jul 18 '05 #6

P: n/a
> Can you give an example of what you mean, in Perl as well as what you
hoped
would work in Python? I couldn't quite understand what it is that you're trying to do.
OK, actually on second test, the problem is mostly with IDLE, but not
totally. When I hit F5 under IDLE, it behaves differently with respect to
the command window then if I just run it by double-clicking on the file.

Here is an example:

BatchTest.bat:

set MYVAR=3
dir
pause
dir
echo %MYVAR%
pause

BatchTest.py:

# the intention is to do the same thing as BatchTest.bat, but it doesn't
work under either IDLE or by double-clicking
# in particular the environment variable is not saved, and it doesn't work
if I replace os.system with os.popen

import os

os.system("set MYVAR=3")
os.system("dir")
os.system("pause")
os.system("dir")
os.system("echo %MYVAR%")
os.system("pause")

BatchTest.pl:

# this actually does the same thing as Python, I was mistaken. I was
mislead by the IDLE behavior.

system('set MYVAR=3');
system('dir');
system('pause');
system('dir');
system('echo %MYVAR%');
system('pause');

The general idea is that it would be nice if there weren't any differences
between the batch file and python. From a practical standpoint, it would
encourage a lot of people to switch from nasty batch files to Python scripts
if you could just surround the entire thing with os.batch(' ') or some
similar sort of mechanical textual substitution. Then you could clean it up
gradually.

I am aware of os.environ and such, and that is useful, but it's not really
the point.

Of course I could write a function to take a bunch of strings, write a batch
file, save the working directory, execute it, restore the current directory,
then delete the batch file, but that seems like an awful hack. Though I
probably will do that at some point.
What's the deal with that? I thought Python started out as a scripting
language. And that seems like the most basic thing that a scripting
language should do.


Dunno, although MS-DOS shell scripting is certainly a small subset of

scripting in general. Maybe with a concrete example somebody will be able to give you a hand.


It is a small subset, but an important subset. Shell scripting started
probably when people got sick of typing the same commands into the prompt.
For a language to really support shell scripting, it should provide a way of
automating the process of typing in the commands. As in, there should be no
difference whether you're actually typing, or you're running the script.

If there is a way and I don't know about it, I would be happy to hear about
it. But I do think it is a pretty big hole.

MB
Jul 18 '05 #7

P: n/a
"Moosebumps" <cr**@crud.com> schreef:
BatchTest.py:

# the intention is to do the same thing as BatchTest.bat, [...]
# in particular the environment variable is not saved,


BatchTest.bat sets the environment variable in the same shell that
executes it, BatchTest.py sets the environment variables in a subshell, and
the changes made in the subshell are discarded when it terminates.

--
JanC

"Be strict when sending and tolerant when receiving."
RFC 1958 - Architectural Principles of the Internet - section 3.9
Jul 18 '05 #8

P: n/a
Each of your system calls spawns it's own separate shell with its own
set of environment variables. You probably want to look into os.environ
(python) or %ENV (perl) to set your shell variables.
On Fri, 2004-01-23 at 23:23, Moosebumps wrote:
Can you give an example of what you mean, in Perl as well as what you

hoped
would work in Python? I couldn't quite understand what it is that you're

trying
to do.


OK, actually on second test, the problem is mostly with IDLE, but not
totally. When I hit F5 under IDLE, it behaves differently with respect to
the command window then if I just run it by double-clicking on the file.

Here is an example:

BatchTest.bat:

set MYVAR=3
dir
pause
dir
echo %MYVAR%
pause

BatchTest.py:

# the intention is to do the same thing as BatchTest.bat, but it doesn't
work under either IDLE or by double-clicking
# in particular the environment variable is not saved, and it doesn't work
if I replace os.system with os.popen

import os

os.system("set MYVAR=3")
os.system("dir")
os.system("pause")
os.system("dir")
os.system("echo %MYVAR%")
os.system("pause")

BatchTest.pl:

# this actually does the same thing as Python, I was mistaken. I was
mislead by the IDLE behavior.

system('set MYVAR=3');
system('dir');
system('pause');
system('dir');
system('echo %MYVAR%');
system('pause');

The general idea is that it would be nice if there weren't any differences
between the batch file and python. From a practical standpoint, it would
encourage a lot of people to switch from nasty batch files to Python scripts
if you could just surround the entire thing with os.batch(' ') or some
similar sort of mechanical textual substitution. Then you could clean it up
gradually.

I am aware of os.environ and such, and that is useful, but it's not really
the point.

Of course I could write a function to take a bunch of strings, write a batch
file, save the working directory, execute it, restore the current directory,
then delete the batch file, but that seems like an awful hack. Though I
probably will do that at some point.
What's the deal with that? I thought Python started out as a scripting
language. And that seems like the most basic thing that a scripting
language should do.


Dunno, although MS-DOS shell scripting is certainly a small subset of

scripting
in general. Maybe with a concrete example somebody will be able to give

you a
hand.


It is a small subset, but an important subset. Shell scripting started
probably when people got sick of typing the same commands into the prompt.
For a language to really support shell scripting, it should provide a way of
automating the process of typing in the commands. As in, there should be no
difference whether you're actually typing, or you're running the script.

If there is a way and I don't know about it, I would be happy to hear about
it. But I do think it is a pretty big hole.

MB


Jul 18 '05 #9

P: n/a
Each of your system calls spawns it's own separate shell with its own
set of environment variables. You probably want to look into os.environ
(python) or %ENV (perl) to set your shell variables.

On Fri, 2004-01-23 at 23:23, Moosebumps wrote:
Can you give an example of what you mean, in Perl as well as what you

hoped
would work in Python? I couldn't quite understand what it is that you're

trying
to do.


OK, actually on second test, the problem is mostly with IDLE, but not
totally. When I hit F5 under IDLE, it behaves differently with respect to
the command window then if I just run it by double-clicking on the file.

Here is an example:

BatchTest.bat:

set MYVAR=3
dir
pause
dir
echo %MYVAR%
pause

BatchTest.py:

# the intention is to do the same thing as BatchTest.bat, but it doesn't
work under either IDLE or by double-clicking
# in particular the environment variable is not saved, and it doesn't work
if I replace os.system with os.popen

import os

os.system("set MYVAR=3")
os.system("dir")
os.system("pause")
os.system("dir")
os.system("echo %MYVAR%")
os.system("pause")

BatchTest.pl:

# this actually does the same thing as Python, I was mistaken. I was
mislead by the IDLE behavior.

system('set MYVAR=3');
system('dir');
system('pause');
system('dir');
system('echo %MYVAR%');
system('pause');

The general idea is that it would be nice if there weren't any differences
between the batch file and python. From a practical standpoint, it would
encourage a lot of people to switch from nasty batch files to Python scripts
if you could just surround the entire thing with os.batch(' ') or some
similar sort of mechanical textual substitution. Then you could clean it up
gradually.

I am aware of os.environ and such, and that is useful, but it's not really
the point.

Of course I could write a function to take a bunch of strings, write a batch
file, save the working directory, execute it, restore the current directory,
then delete the batch file, but that seems like an awful hack. Though I
probably will do that at some point.
What's the deal with that? I thought Python started out as a scripting
language. And that seems like the most basic thing that a scripting
language should do.


Dunno, although MS-DOS shell scripting is certainly a small subset of

scripting
in general. Maybe with a concrete example somebody will be able to give

you a
hand.


It is a small subset, but an important subset. Shell scripting started
probably when people got sick of typing the same commands into the prompt.
For a language to really support shell scripting, it should provide a way of
automating the process of typing in the commands. As in, there should be no
difference whether you're actually typing, or you're running the script.

If there is a way and I don't know about it, I would be happy to hear about
it. But I do think it is a pretty big hole.

MB


Jul 18 '05 #10

P: n/a
It is a small subset, but an important subset. Shell scripting started
probably when people got sick of typing the same commands into the prompt.
For a language to really support shell scripting, it should provide a way of
automating the process of typing in the commands. As in, there should be no
difference whether you're actually typing, or you're running the script.


Python is not a shell, nor scripting language. It does contain an
interactive interpreter for executing Python code, and it does have
support for executing programs through calling a shell, but that does
not necessitate (or warrant) it having every feature for shell scripting
that everyone wants.

JanC makes a great point about the fact that commands are run in a
subshell, and any environment changes are lost when the subshell
terminates. I believe this is by design.

Perhaps you should look into os.popen2 and friends. You can execute a
command shell (cmd.exe or command.com), send it commands, and read its
output. On Windows it is a little awkward right now, but os.popen5 is
supposed to make it easy to deal with such things. Hopefully it will
make it into Python 2.4.

- Josiah
Jul 18 '05 #11

P: n/a
Moosebumps wrote:
[snip]
# this actually does the same thing as Python, I was mistaken. I was
mislead by the IDLE behavior. [snip]
The general idea is that it would be nice if there weren't any differences
between the batch file and python. From a practical standpoint, it would
encourage a lot of people to switch from nasty batch files to Python scripts
if you could just surround the entire thing with os.batch(' ') or some
similar sort of mechanical textual substitution. Then you could clean it up
gradually.
Ah, now I understand what you meant. In practical terms, there isn't much of a
difference between executing Python commands in batch mode or interactively
from the *Python* command prompt (the interactive interpreter), and I think
that's what this all boils down to. A DOS window is an interactive command
prompt for the MS-DOS batch language; Python is a different language and has
its own command prompt, so it wouldn't really make sense for commands in one
language to be valid in the other. It's easy to miss this point though since
its common to access the Python "command prompt" by first launching the DOS
command prompt, but they really are two different languages with two different
purposes.
What's the deal with that? I thought Python started out as a scripting
language. And that seems like the most basic thing that a scripting
language should do.


Dunno, although MS-DOS shell scripting is certainly a small subset of

scripting
in general. Maybe with a concrete example somebody will be able to give

you a
hand.


It is a small subset, but an important subset. Shell scripting started
probably when people got sick of typing the same commands into the prompt.
For a language to really support shell scripting, it should provide a way of
automating the process of typing in the commands. As in, there should be no
difference whether you're actually typing, or you're running the script.


Right, and there is little difference between batch and interactive modes of
Python, and little difference between batch and interactive modes of MS-DOS,
but what you're wishing for is for batch mode of language A to be the same as
interactive mode of language B. Unless one language is a subset of the other,
that just doesn't make sense (and I'm very pleased that Python is not a
superset of DOS batch files! :) )
If there is a way and I don't know about it, I would be happy to hear about
it. But I do think it is a pretty big hole.


I don't - Python is a general purpose programming language that happens to be
pretty good for so-called "shell scripting" too, but the language is useful in
so many other domains that it wouldn't make sense to tailor it too heavily to
this particular type of problem. Further, if it were to be tailored to make
shell scripting even easier, I really doubt that basing it on the MS-DOS batch
language would be a good idea - even something as quirky as bash would be far
better.

-Dave
Jul 18 '05 #12

P: n/a
On Sat, 24 Jan 2004 04:23:40 GMT, "Moosebumps" <cr**@crud.com> wrote:
Can you give an example of what you mean, in Perl as well as what you

hoped
would work in Python? I couldn't quite understand what it is that you're

trying
to do.


OK, actually on second test, the problem is mostly with IDLE, but not
totally. When I hit F5 under IDLE, it behaves differently with respect to
the command window then if I just run it by double-clicking on the file.

Here is an example:

BatchTest.bat:

set MYVAR=3
dir
pause
dir
echo %MYVAR%
pause

BatchTest.py:

# the intention is to do the same thing as BatchTest.bat, but it doesn't
work under either IDLE or by double-clicking
# in particular the environment variable is not saved, and it doesn't work
if I replace os.system with os.popen

import os

os.system("set MYVAR=3")
os.system("dir")
os.system("pause")
os.system("dir")
os.system("echo %MYVAR%")
os.system("pause")

BatchTest.pl:

# this actually does the same thing as Python, I was mistaken. I was
mislead by the IDLE behavior.

system('set MYVAR=3');
system('dir');
system('pause');
system('dir');
system('echo %MYVAR%');
system('pause');

The general idea is that it would be nice if there weren't any differences
between the batch file and python. From a practical standpoint, it would
encourage a lot of people to switch from nasty batch files to Python scripts
if you could just surround the entire thing with os.batch(' ') or some
similar sort of mechanical textual substitution. Then you could clean it up
gradually.

I am aware of os.environ and such, and that is useful, but it's not really
the point.

Of course I could write a function to take a bunch of strings, write a batch
file, save the working directory, execute it, restore the current directory,
then delete the batch file, but that seems like an awful hack. Though I
probably will do that at some point.
> What's the deal with that? I thought Python started out as a scripting
> language. And that seems like the most basic thing that a scripting
> language should do.


Dunno, although MS-DOS shell scripting is certainly a small subset of

scripting
in general. Maybe with a concrete example somebody will be able to give

you a
hand.


It is a small subset, but an important subset. Shell scripting started
probably when people got sick of typing the same commands into the prompt.
For a language to really support shell scripting, it should provide a way of
automating the process of typing in the commands. As in, there should be no
difference whether you're actually typing, or you're running the script.

If there is a way and I don't know about it, I would be happy to hear about
it. But I do think it is a pretty big hole.

MB

If you're looking for more shell-like behavior, look into IPython at
http://ipython.scipy.org/. Although it still won't "export" your
environment variables, or make your calls to os.system have a unique
environment, you can do things like 'ls' (you can probably configure
dir to work, but by default it provides access to the python builtin
function of that name).

Here is an excerpt that does some of the things in Mooosebump's
sample:

In [15]: import os
In [16]: os.environ['MYVAR'] = '3'
In [17]: os.system('echo %MYVAR%')
3
Out[17]: 0
In [18]: cd \
C:\
In [19]: ls /w/ad P*
Volume in drive C has no label.
Volume Serial Number is A096-107C

Directory of C:\

[Program Files] [Python23]
0 File(s) 0 bytes
2 Dir(s) 871,232 bytes free
Notice the unescaped backslash in line 18, and the "DOS" command line
options "/w/ad" and "P*" wildcard on line 19.

This still might not be what you're after, but it's a step in the
right direction.
--dang
Jul 18 '05 #13

This discussion thread is closed

Replies have been disabled for this discussion.