469,926 Members | 1,526 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,926 developers. It's quick & easy.

Piping data into Python on the command line - Windows 2000

Hi

I'm trying to pipe data into a python program on Windows 2000, on the
command line.

Like this:
dir | myProgram.py
Here's what I tried:

== readFromStdin.py ==
#!/usr/bin.env python
import sys
print sys.sdtin.readlines()
When I run it on Linux and Windows, results differ
ls -l | ./readFromStdin.py - Works on Linux

dir | readFromStdin.py - Doesn't work on win2000
IOError: [Errno 9] Bad file descriptor

The ultimate goal is to write python scripts that I can use from
Komodo's (Python IDE) Run Command feature. I'm running Komodo on
Windows 2000.

I want to highlight some text in Komodo, and run my command, pasting
the output of my program back in to the file I was editing in Komodo.

Komodo makes this easy with built-in commands like sort. You just
select the "Pass Selection As Input" and "Insert Output" options,
highlight some text, type "sort" in the Run Command box, and voila,
Komodo pipes your highlighted text to sort, and pastes the sorted text
back into your editor window.

I want to write a Python program that can behave in the same way as
sort does, for use with Komodo on Windows 2000.

Thanks!

Christian Long
Jul 18 '05 #1
4 9558
ch************@yahoo.com (Christian Long) writes:
dir | readFromStdin.py - Doesn't work on win2000
IOError: [Errno 9] Bad file descriptor


I don't know if you're saying you have a problem with Komodo, or just
during your specific tests, but the above case (presuming that you're
running this from a standard Windows command, cmd.exe) is a bug in
Windows cmd.exe. When trying to use I/O redirection and registered
file extensions to automatically find an executable, the redirection
doesn't work properly. If you change this command to:

dir | python readFromStdin.py

it should work (replace "python" with the full path to your python.exe
if it isn't in your path).

Whether or not this affects Komodo's Run box depends on just how
Komodo starts up the child process. It's possible that Komodo is just
executing cmd.exe and passing in its command, in which case supplying
a Python script directly may trigger the same bug as above (or it may
not since it's actually the stdin/stdout to cmd.exe and thus Komodo
that is being passed to the Python script). If it doesn, then I
expect you'll need to be explicit about Python being the executable
you are running. Either that or maybe write a wrapper batch file
which can contain the explicit reference to python, to avoid having to
type it into the Komodo Run box.

BTW, another alternative to your script would be:

import fileinput

for line in fileinput.input():
print line,

which will work both with data on stdin as well as having filenames
specified on the command line if desired (also similar to how the Unix
sort command and many other Unix utilities work). It also doesn't
need to bring all the input into memory before processing (although
you could get that with your prior script by using readline() rather
than readlines()). The main drawback is that it's not the fastest way
to process lines, but its performance has gotten better in recent
Python releases due to general improvements in file I/O processing.

-- David
Jul 18 '05 #2
David Bolen <db**@fitlinxx.com> schreef:
I don't know if you're saying you have a problem with Komodo, or just
during your specific tests, but the above case (presuming that you're
running this from a standard Windows command, cmd.exe) is a bug in
Windows cmd.exe. When trying to use I/O redirection and registered
file extensions to automatically find an executable, the redirection
doesn't work properly. If you change this command to:

dir | python readFromStdin.py

it should work (replace "python" with the full path to your python.exe
if it isn't in your path).


I don't know if this is a bug in cmd.exe, but at least command.com on Win9x
does know nothing about "registered extensions" unless you use the "start"
command.

dir | start readFromStdin.py

This works but "start" opens a new window that is closed when the script
exits (you don't get the time to read the output).

--
JanC

"Be strict when sending and tolerant when receiving."
RFC 1958 - Architectural Principles of the Internet - section 3.9
Jul 18 '05 #3
ch************@yahoo.com (Christian Long) wrote in news:88**************************@posting.google.c om:
I'm trying to pipe data into a python program on Windows 2000, on the
command line.

Like this:
dir | myProgram.py

This is a well known problem with Windows command line processor.
Try searching Google groups for "Python pipe win2k" and you will
find several similar threads.

e.g.
http://groups.google.co.uk/groups?th...vanderbilt.edu

Try running your command with an explicit call to the Python interpreter:

dir | python myProgram.py

--
Duncan Booth du****@rcp.co.uk
int month(char *p){return(124864/((p[0]+p[1]-p[2]&0x1f)+1)%12)["\5\x8\3"
"\6\7\xb\1\x9\xa\2\0\4"];} // Who said my code was obscure?
Jul 18 '05 #4
I've been writing an ANSI parser for the windows console so that I can view my python output with colours, etc, and I found the same problem.

Changing the launching of the python script to explicitly use the python interpreter helps, WTF!

Thanks Guys!

Norman

--
- Norman Rasmussen
- Email: norman@rasmussen.co.za
- Home page: http://norman.rasmussen.co.za/
Sep 18 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by Ryan Smith | last post: by
1 post views Thread by Edward WIJAYA | last post: by
3 posts views Thread by Mike Moum | last post: by
1 post views Thread by Andrew McCall | last post: by
2 posts views Thread by Mick Duprez | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.