Hi! This is not a bug, at least, not a bug of bash... ssh does as it always does unless instructed otherwise: hogs the STDIN for itself. (However, because it has a command given on the command line to execute, it doesn't actually do anything for the lines in STDIN, just reads them.) The varying amount of lines output depends, I think, on how many lines from tmp/koe.c bash had time to buffer before calling the first instance of ssh (which then hogs all the rest of the lines - the later instances but echo the lines in the buffer and do nothing else).
(I was able to replicate the 'bug' without the pipeline part. Probably the pipeline used caused that there was time to buffer less lines.) There are a couple of obvious 'workarounds': while read rivi; do ssh -n oiva echo "'$rivi'" | tr a a; done < tmp/koe.c (the one recommended in ssh manual) while read rivi; do ssh oiva echo "'$rivi'"</dev/null | tr a a; done < tmp/koe.c (does exactly the same thing as the line before) while read rivi; do ssh oiva echo "'$rivi'"</dev/stdin | tr a a; done < tmp/koe.c (you can actually get ssh to get its stdin from almost anywhere, as long as it isn't the stdin of the subshell invoked by the while statement - yes, from even the same file - different FD. But I don't see much point in other options besides /dev/null, since they just cause the ssh to read the files without doing anything with the content) This won't work - as I said, ssh throws away the contents of STDIN when it has a command to execute - but it goes to show that it does read it: --clip-- t...@aulis:~$ ssh oiva "while read rivi; do echo '$rivi'; done" < tmp/koe.c t...@aulis:~$ wc -l tmp/koe.c 9 tmp/koe.c t...@aulis:~$ ssh oiva "while read rivi; do echo '$rivi'; done" < tmp/koe.c|wc -l 9 t...@aulis:~$ --clip-- HTH. -- Janne Peltonen <janne.pelto...@sange.fi> PGP Key ID: 0x9CFAC88B -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
