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

sys.stdin and two CTRL-Ds

P: n/a
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
Jul 1 '06 #1
Share this Question
Share on Google+
8 Replies


P: n/a
On 2/07/2006 5:02 AM, Christoph Haas wrote:
> 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
Jul 1 '06 #2

P: n/a
In article <44**************@lexicon.net>,
John Machin <sj******@lexicon.netwrote:
>-u unbuffers sys.stdout
and sys.stderr (and makes them binary, which wouldn't be a good idea on
a Windows box).
Why not?
Jul 2 '06 #3

P: n/a
On 2/07/2006 3:48 PM, Lawrence D'Oliveiro wrote:
In article <44**************@lexicon.net>,
John Machin <sj******@lexicon.netwrote:
>-u unbuffers sys.stdout
and sys.stderr (and makes them binary, which wouldn't be a good idea on
a Windows box).

Why not?
If binary, '\n' would appear as LF alone rather than CR LF.
Jul 2 '06 #4

P: n/a
In article <44******@news.eftel.com>,
John Machin <sj******@lexicon.netwrote:
>On 2/07/2006 3:48 PM, Lawrence D'Oliveiro wrote:
>In article <44**************@lexicon.net>,
John Machin <sj******@lexicon.netwrote:
>>-u unbuffers sys.stdout
and sys.stderr (and makes them binary, which wouldn't be a good idea on
a Windows box).

Why not?

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.
Jul 3 '06 #5

P: n/a
On 3/07/2006 4:45 PM, Lawrence D'Oliveiro wrote:
In article <44******@news.eftel.com>,
John Machin <sj******@lexicon.netwrote:
>On 2/07/2006 3:48 PM, Lawrence D'Oliveiro wrote:
>>In article <44**************@lexicon.net>,
John Machin <sj******@lexicon.netwrote:

-u unbuffers sys.stdout
and sys.stderr (and makes them binary, which wouldn't be a good idea on
a Windows box).
Why not?
If binary, '\n' would appear as LF alone rather than CR LF.

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?

Jul 3 '06 #6

P: n/a
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 wrote:
Why should that matter? I thought Windows (the NT line) was
POSIX-compliant.
Jul 3 '06 #7

P: n/a
In article <44********@news.eftel.com>,
John Machin <sj******@lexicon.netwrote:
>On 3/07/2006 4:45 PM, Lawrence D'Oliveiro wrote:
>I thought Windows (the NT line) was
POSIX-compliant.

What on earth gave you that idea?
<http://fuckinggoogleit.com/?query=windows+nt+posix>
Jul 3 '06 #8

P: n/a
On 3/07/2006 9:14 PM, Lawrence D'Oliveiro wrote:
In article <44********@news.eftel.com>,
John Machin <sj******@lexicon.netwrote:
>On 3/07/2006 4:45 PM, Lawrence D'Oliveiro wrote:
>>I thought Windows (the NT line) was
POSIX-compliant.
What on earth gave you that idea?

<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]?
Jul 3 '06 #9

This discussion thread is closed

Replies have been disabled for this discussion.