Nice "bug" to loose a contest

[stdazi]

Hello,

Yesterday, I was at a programming competition. We programmed on Linux
liveCD's and Python was one of the allowed languages (among C and
Java). I cared just about the algorithmic approach so I used Python.
One of the main rules is, that the code reads its standard input and
dumps the result on the standard output. Here happened my bigger
programming mistake ever - I used the following approach :

====
import sys
print sys.stdout.readlines() # TYPO ! stdin != stdout
====

So the WEIRD issue is, that it worked and, executing the following
code I get :

====
azi@magicb0x ~ $ python la.py
test
test #2
['test \n', 'test #2\n']
azi@magicb0x ~ $
====

Ok, as the algorithm worked perfectly, and all the test cases we were
given were positive, I've continued with the next problem, copy/
pasting the above idiom... When they tested the code, they used file
redirection like :

==
python la.py < /somefile
==

And, my code resulted in no output/input (=0 points), which can be
proved here too :

====
azi@magicb0x ~ $ python la.py < /etc/passwd
===

Some friend of mine told me that's the Unix way, (stdout can act like
stdin) so I tried some C code :

===
1 #include <stdio.h>
2
3 int main() {
4 char buf[120];
5 while (fgets(buf, sizeof(buf), stdout) != NULL) {
6 puts(buf);
7 }
8 return 0;
9}
===

The code returns with no delay, so I'm really wondering where is that
nice sys.{stdin,stdout} feature inplemented as pydoc doesn't mention
anything. I'd spot the mistake before submitting the problem solutions
if it was written in C :)

Thanks!

[aspineux]

This code works like the python one,
I dont use buffered stdio f... functions,
but the more 'system call' read and write

int main()
{
char buf[120];
int len;

while (len=read(1, buf, sizeof(buf))) {
write(1, buf, len);
}
return 0;
}

I dont understand what is appening,
but you have to know their is a link between
stdin and stdout in 'terminal mode', when you make a read on stdin,
stdout is automatically flushed, this link disappears when onr is not
liked to a terminal.
This is to facilitate user input, to avoid to put a flush after each
write,
in fact before any user input.

Hope someone else will give the trick

On 8 avr, 12:52, "stdazi" <[e-mail]:

Hello,

Yesterday, I was at a programming competition. We programmed on Linux
liveCD's and Python was one of the allowed languages (among C and
Java). I cared just about the algorithmic approach so I used Python.
One of the main rules is, that the code reads its standard input and
dumps the result on the standard output. Here happened my bigger
programming mistake ever - I used the following approach :

====
import sys
print sys.stdout.readlines() # TYPO ! stdin != stdout
====

So the WEIRD issue is, that it worked and, executing the following
code I get :

====
azi@magicb0x ~ $ python la.py
test
test #2
['test \n', 'test #2\n']
azi@magicb0x ~ $
====

Ok, as the algorithm worked perfectly, and all the test cases we were
given were positive, I've continued with the next problem, copy/
pasting the above idiom... When they tested the code, they used file
redirection like :

==
python la.py < /somefile
==

And, my code resulted in no output/input (=0 points), which can be
proved here too :

====
azi@magicb0x ~ $ python la.py < /etc/passwd

===

Some friend of mine told me that's the Unix way, (stdout can act like
stdin) so I tried some C code :

===
1 #include <stdio.h>
2
3 int main() {
4 char buf[120];
5 while (fgets(buf, sizeof(buf), stdout) != NULL) {
6 puts(buf);
7 }
8 return 0;
9}
===

The code returns with no delay, so I'm really wondering where is that
nice sys.{stdin,stdout} feature inplemented as pydoc doesn't mention
anything. I'd spot the mistake before submitting the problem solutions
if it was written in C :)

Thanks!

[azi.stdout]

On Apr 8, 1:40 pm, "aspineux" <[e-mail]:

This code works like the python one,
I dont use buffered stdio f... functions,
but the more 'system call' read and write

int main()
{
char buf[120];
int len;

while (len=read(1, buf, sizeof(buf))) {
write(1, buf, len);
}
return 0;

}

Yeah, I've noticed that too, altough I'm clueless on how stdio handles
that differently. Now I'm wondering, what's the behaviour of the
Python snippet that reads from stdout in Windows.. Can someone on
Windows try it and report please?

[Gabriel Genellina]

En Mon, 09 Apr 2007 09:19:16 -0300, <az********@gmail.comescribió:

Yeah, I've noticed that too, altough I'm clueless on how stdio handles
that differently. Now I'm wondering, what's the behaviour of the
Python snippet that reads from stdout in Windows.. Can someone on
Windows try it and report please?

It does the right thing:

pyprint sys.stdout.readlines()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
IOError: [Errno 9] Bad file descriptor

--
Gabriel Genellina

[azi.stdout]

On Apr 9, 2:47 pm, "Gabriel Genellina" <[e-mail]:

En Mon, 09 Apr 2007 09:19:16 -0300, <[e-mail]ó:

Yeah, I've noticed that too, altough I'm clueless on how stdio handles
that differently. Now I'm wondering, what's the behaviour of the
Python snippet that reads from stdout in Windows.. Can someone on
Windows try it and report please?

It does the right thing:

pyprint sys.stdout.readlines()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
IOError: [Errno 9] Bad file descriptor

--
Gabriel Genellina

I'm wondering if this could be treated as a bug of some kind? I always
thought that the purpose of "higher" interpreted languages is to hide
the implementation details as much as possible, offering a
unique,equal and transparent environment on all systems (as much as
this is possible).

[aspineux]

On 8 avr, 13:40, "aspineux" <[e-mail]:

This code works like the python one,
I dont use buffered stdio f... functions,
but the more 'system call' read and write

int main()
{
char buf[120];
int len;

while (len=read(1, buf, sizeof(buf))) {
write(1, buf, len);
}
return 0;

}

I dont understand what is appening,

But I have an idea !

It is possible to open a file in RW mode, nothing exceptional with
that.
And when connected in a terminal, you are connected through a file
called a PTY !
This "file" is open in RW !

File descriptors 0, 1 and 2 are certainly a "view" of this PTY and
then in fact the same thing !

but you have to know their is a link between
stdin and stdout in 'terminal mode', when you make a read on stdin,
stdout is automatically flushed, this link disappears when onr is not
liked to a terminal.
This is to facilitate user input, to avoid to put a flush after each
write,
in fact before any user input.

Hope someone else will give the trick

On 8 avr, 12:52, "stdazi" <[e-mail]:

Hello,

Yesterday, I was at a programming competition. We programmed on Linux
liveCD's and Python was one of the allowed languages (among C and
Java). I cared just about the algorithmic approach so I used Python.
One of the main rules is, that the code reads its standard input and
dumps the result on the standard output. Here happened my bigger
programming mistake ever - I used the following approach :

====
import sys
print sys.stdout.readlines() # TYPO ! stdin != stdout
====

So the WEIRD issue is, that it worked and, executing the following
code I get :

====
azi@magicb0x ~ $ python la.py
test
test #2
['test \n', 'test #2\n']
azi@magicb0x ~ $
====

Ok, as the algorithm worked perfectly, and all the test cases we were
given were positive, I've continued with the next problem, copy/
pasting the above idiom... When they tested the code, they used file
redirection like :

==
python la.py < /somefile
==

And, my code resulted in no output/input (=0 points), which can be
proved here too :

====
azi@magicb0x ~ $ python la.py < /etc/passwd

===

Some friend of mine told me that's the Unix way, (stdout can act like
stdin) so I tried some C code :

===
1 #include <stdio.h>
2
3 int main() {
4 char buf[120];
5 while (fgets(buf, sizeof(buf), stdout) != NULL) {
6 puts(buf);
7 }
8 return 0;
9}
===

The code returns with no delay, so I'm really wondering where is that
nice sys.{stdin,stdout} feature inplemented as pydoc doesn't mention
anything. I'd spot the mistake before submitting the problem solutions
if it was written in C :)

Thanks!