On Thu, Jan 6, 2011 at 12:03 PM, Jeff King <peff@xxxxxxxx> wrote:
> On Thu, Jan 06, 2011 at 11:50:58AM +1300, Chris Packham wrote:
>
>> Actually this might be a ssh/bash bug (feature?). There is different
>> behaviour between
>>
>> Â find . -maxdepth 1 -type d -a ! -name '\.*' | while read; do echo
>> $REPLY && ssh localhost ls /; done
>>
>> and
>>
>> Â find . -maxdepth 1 -type d -a ! -name '\.*' | while read; do echo
>> $REPLY && ls /; done
>
> Ssh will opportunistically eat data on stdin to send to the other side,
> even though the command on the other side ("ls" in this case) will never
> read it. Because of course ssh has no way of knowing that, and is trying
> to be an interactive terminal. So it ends up eating some random amount
> of the data you expected to go to the "read" call.
>
> You can use the "-n" option to suppress it. For example:
>
> Â$ (echo foo; echo bar) |
> Â Âwhile read line; do
> Â Â Âecho local $line
> Â Â Âssh host "echo remote $line"
> Â Âdone
>
> produces:
>
> Âlocal foo
> Âremote foo
>
> but:
>
> Â$ (echo foo; echo bar) |
> Â Âwhile read line; do
> Â Â Âecho local $line
> Â Â Âssh -n host "echo remote $line"
> Â Âdone
>
> produces:
>
> Âlocal foo
> Âremote foo
> Âlocal bar
> Âremote bar
>
> which is what you want.
>
> -Peff
Thanks that makes sense and adding -n to my ssh invocations solves the problem.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html