sys.stdin and two CTRL-Ds

[Christoph Haas]

Hi...

I encountered a problem that - according to my google search - other
people have found, too. Example code:

import sys
for line in sys.stdin:
print line

Running this code in Python 2.3 or 2.4 has the problem that I need to
send two EOFs (Ctrl-D) to break out of that loop.

Use case is a piped Python script that I run as a "CustomLog" pipe for
an Apache web server. I want to run all the log output through that pipe
but haven't had much luck. First it takes ages until the script
processes the input (even though I ran Python with "-u" to make it
unbuffered) and then the script needs one EOF to do something with the
input and a second EOF to break out of the loop.

Is this a bug? I'm close to write a Perl script for this case.

Regards
Christoph

 

[John Machin]

Hi...

I encountered a problem that - according to my google search - other
people have found, too. Example code:

import sys
for line in sys.stdin:
print line

Running this code in Python 2.3 or 2.4 has the problem that I need to
send two EOFs (Ctrl-D) to break out of that loop.

Use case is a piped Python script that I run as a "CustomLog" pipe for
an Apache web server. I want to run all the log output through that pipe
but haven't had much luck. First it takes ages until the script
processes the input (even though I ran Python with "-u" to make it
unbuffered)

Which "it" did you expect to make unbuffered? -u unbuffers sys.stdout
and sys.stderr (and makes them binary, which wouldn't be a good idea on
a Windows box). If you are concerned that output shows up in real time,
use sys.stdXXX.flush().

and then the script needs one EOF to do something with the
input and a second EOF to break out of the loop.

Is this a bug? I'm close to write a Perl script for this case.

I can reproduce your problem on Windows with Python 2.4.2 (note ^Z is
EOF for Windows):

|>> import sys
|>> for line in sys.stdin:
.... print >> sys.stderr, "->", repr(line)
....
line1
line2
line3
^Z
-> 'line1\n'
-> 'line2\n'
-> 'line3\n'
^Z
|>>

However this worked for me :

|>> import sys
|>> while 1:
.... line = sys.stdin.readline()
.... if not line: break
.... print >> sys.stderr, "->", repr(line)
....
line1
-> 'line1\n'
line2
-> 'line2\n'
^Z
|>>

The Library Reference Manual, section 2.3.9 (File Objects) says:
"""
Files support the iterator protocol. Each iteration returns the same
result as file.readline(), and iteration ends when the readline() method
returns an empty string.
"""

So yes, looks like a bug to me, but perhaps you don't need use Perl

HTH,
John

 

[Dennis Lee Bieber]

Use case is a piped Python script that I run as a "CustomLog" pipe for

I suspect one of the <ctrl-d> is being eaten by the process sourcing
the pipe; when that process goes away (possibly without cleaning the

an Apache web server. I want to run all the log output through that pipe
but haven't had much luck. First it takes ages until the script
processes the input (even though I ran Python with "-u" to make it
unbuffered) and then the script needs one EOF to do something with the

That only means the Python side is not doing buffering -- but
doesn't say anything about the side generating the data; as I recall,
the common behavior -- in the OS runtime -- is unbuffered to terminals,
buffered to pipes.

input and a second EOF to break out of the loop.

Is this a bug? I'm close to write a Perl script for this case.

Regards
Christoph

--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/

 

[Lawrence D'Oliveiro]

-u unbuffers sys.stdout
and sys.stderr (and makes them binary, which wouldn't be a good idea on
a Windows box).

Why not?

 

[John Machin]

Why not?

If binary, '\n' would appear as LF alone rather than CR LF.

 

[Lawrence D'Oliveiro]

If binary, '\n' would appear as LF alone rather than CR LF.

Why should that matter? I thought Windows (the NT line) was
POSIX-compliant.

 

[John Machin]

Why should that matter?

Because the contents of the output would be different. Haven't you ever
wondered why (or read the manuals that explain why) Python, C , etc file
I/O libraries have a text mode and a binary mode?

I thought Windows (the NT line) was
POSIX-compliant.

What on earth gave you that idea?

 

[cmdrrickhunter]

I may be wrong, but I've never heard of Windows being fully posix
compliant. I guarentee you that they dont support pthreads.

It is possible that by "posix compliant" the marketting execs mean
"supports all posix commands which dont interfere with our way of doing
things"

Windows version of python always uses \r\n for line ends (which are
then combined into a single \n character when read). This bears strong
resemblance to the carriage return line feed combination required by
typerwriters before the computer era. Wordpad will read Unix line ends
(\n) if it has to, notepad wont even try. Mac used to use \r for line
ends, just to be the odd ball. I think they may have stopped that with
OSX. Any mac user want to cover this one?

Whats especially frustrating is the cygwin version of python. If you
configure things wrong with the cygwin line ends, you can have python
swear its outputing \n while its really coughing out \r\n's

 

[Lawrence D'Oliveiro]

What on earth gave you that idea?

<http://fuckinggoogleit.com/?query=windows+nt+posix>

 

[John Machin]

<http://fuckinggoogleit.com/?query=windows+nt+posix>

Thank you for your elegant and witty response.

The POSIX sub-system of Windows NT 4+ is POSIX-compliant to some degree.
This is not the same as saying that the whole of Windows is
POSIX-compliant. It means that people who write applications using that
subsytem can achieve the same result as if the app was being run on a *x
platform. This is as wonderful and as useless as tits on a bull. So what
do you do if you redirect stdout to a file and a user complains that
Notepad won't grok it? Teach him/her to use vi[m]?