On 8 avr, 13:40, "aspineux" <[EMAIL PROTECTED]> wrote:
> 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" <[EMAIL PROTECTED]> wrote:
>
> > 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 :
>
> > ====
> > [EMAIL PROTECTED] ~ $ python la.py
> > test
> > test #2
> > ['test \n', 'test #2\n']
> > [EMAIL PROTECTED] ~ $
> > ====
>
> > 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 :
>
> > ====
> > [EMAIL PROTECTED] ~ $ 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!
--
http://mail.python.org/mailman/listinfo/python-list
