{"thread":{"id":"26207","subject":"[BUG?] \"git submodule foreach\" when command is ssh","startedAt":"2011-01-05T22:32:27Z","lastAt":"2011-01-05T23:22:17Z","messageCount":5,"participants":["Chris Packham","Jeff King","Seth Robertson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"158996","messageId":"AANLkTi=x2i6NvDNRzbszhk-a-z5AYe46-iUBxQsxJJHC@mail.gmail.com","threadId":"26207","inReplyTo":null,"subject":"[BUG?] \"git submodule foreach\" when command is ssh","fromName":"Chris Packham","fromEmail":"judge.packham@gmail.com","sentAt":"2011-01-05T22:32:27Z","receivedAt":"2011-01-05T22:32:27Z","isPatch":false,"sender":{"key":"judge.packham@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155667?v=4"},"body":"Hi All,\n\nI just noticed something odd with \"git submodule foreach\". I was\nrunning a script to create a backup of each submodule on a server I\nhave ssh access to. I was surprised to find that git submodule foreach\nstopped silently after the first submodule.\n\nA little debugging and I find that\n\ngit submodule foreach 'ssh localhost \"ls /\"' - stops silently after\nthe first module (note that the command does produce the expected\nlisting and there is no error about the command failing).\n\ngit submodule foreach 'echo foo' - works as expected\n\nAny thoughts as to whats going on?\n\n---\ngit version 1.7.3.2\n"},{"id":"158999","messageId":"AANLkTini=GaGSHDX4e1jhPVxKaSayUJoWa=w4u4Rz-+5@mail.gmail.com","threadId":"26207","inReplyTo":"AANLkTi=x2i6NvDNRzbszhk-a-z5AYe46-iUBxQsxJJHC@mail.gmail.com","subject":"Re: [BUG?] \"git submodule foreach\" when command is ssh","fromName":"Chris Packham","fromEmail":"judge.packham@gmail.com","sentAt":"2011-01-05T22:50:58Z","receivedAt":"2011-01-05T22:50:58Z","isPatch":false,"sender":{"key":"judge.packham@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155667?v=4"},"body":"On Thu, Jan 6, 2011 at 11:32 AM, Chris Packham <judge.packham@gmail.com> wrote:\n> Hi All,\n>\n> I just noticed something odd with \"git submodule foreach\". I was\n> running a script to create a backup of each submodule on a server I\n> have ssh access to. I was surprised to find that git submodule foreach\n> stopped silently after the first submodule.\n>\n> A little debugging and I find that\n>\n> git submodule foreach 'ssh localhost \"ls /\"' - stops silently after\n> the first module (note that the command does produce the expected\n> listing and there is no error about the command failing).\n>\n> git submodule foreach 'echo foo' - works as expected\n>\n> Any thoughts as to whats going on?\n>\n> ---\n> git version 1.7.3.2\n>\n\nActually this might be a ssh/bash bug (feature?). There is different\nbehaviour between\n\n  find . -maxdepth 1 -type d -a ! -name '\\.*' | while read; do echo\n$REPLY && ssh localhost ls /; done\n\nand\n\n  find . -maxdepth 1 -type d -a ! -name '\\.*' | while read; do echo\n$REPLY && ls /; done\n"},{"id":"159006","messageId":"201101052302.p05N2E0v002551@no.baka.org","threadId":"26207","inReplyTo":"AANLkTi=x2i6NvDNRzbszhk-a-z5AYe46-iUBxQsxJJHC@mail.gmail.com","subject":"Re: [BUG?] \"git submodule foreach\" when command is ssh","fromName":"Seth Robertson","fromEmail":"in-git@baka.org","sentAt":"2011-01-05T23:02:14Z","receivedAt":"2011-01-05T23:02:14Z","isPatch":false,"sender":{"key":"in-git@baka.org","avatar":null},"body":"\nIn message <AANLkTi=x2i6NvDNRzbszhk-a-z5AYe46-iUBxQsxJJHC@mail.gmail.com>, Chri\ns Packham writes:\n\n    I just noticed something odd with \"git submodule foreach\". I was\n    running a script to create a backup of each submodule on a server I\n    have ssh access to. I was surprised to find that git submodule foreach\n    stopped silently after the first submodule.\n\n    A little debugging and I find that\n\n    git submodule foreach 'ssh localhost \"ls /\"' - stops silently after\n\nPutting some input redirection will work around the problem.\nPresumably some pipe input is going into the ssh accidentally.\n\ngit submodule foreach 'ssh localhost \"ls /\" < /dev/null'\n\nI'll also just take this moment to advertise gitslave\n(http://gitslave.sf.net) as an alternate to submodules which may help\n(or hinder) you--depending on your workflow.  It doesn't suffer from\nthis particular problem in any case.\n\n\t\t\t\t\t-Seth Robertson\n"},{"id":"159001","messageId":"20110105230334.GB9774@sigill.intra.peff.net","threadId":"26207","inReplyTo":"AANLkTini=GaGSHDX4e1jhPVxKaSayUJoWa=w4u4Rz-+5@mail.gmail.com","subject":"Re: [BUG?] \"git submodule foreach\" when command is ssh","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-01-05T23:03:35Z","receivedAt":"2011-01-05T23:03:35Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Jan 06, 2011 at 11:50:58AM +1300, Chris Packham wrote:\n\n> Actually this might be a ssh/bash bug (feature?). There is different\n> behaviour between\n> \n>   find . -maxdepth 1 -type d -a ! -name '\\.*' | while read; do echo\n> $REPLY && ssh localhost ls /; done\n> \n> and\n> \n>   find . -maxdepth 1 -type d -a ! -name '\\.*' | while read; do echo\n> $REPLY && ls /; done\n\nSsh will opportunistically eat data on stdin to send to the other side,\neven though the command on the other side (\"ls\" in this case) will never\nread it. Because of course ssh has no way of knowing that, and is trying\nto be an interactive terminal. So it ends up eating some random amount\nof the data you expected to go to the \"read\" call.\n\nYou can use the \"-n\" option to suppress it. For example:\n\n  $ (echo foo; echo bar) |\n    while read line; do\n      echo local $line\n      ssh host \"echo remote $line\"\n    done\n\nproduces:\n\n  local foo\n  remote foo\n\nbut:\n\n  $ (echo foo; echo bar) |\n    while read line; do\n      echo local $line\n      ssh -n host \"echo remote $line\"\n    done\n\nproduces:\n\n  local foo\n  remote foo\n  local bar\n  remote bar\n\nwhich is what you want.\n\n-Peff\n"},{"id":"159003","messageId":"AANLkTikCUKbHUrvXjWVyzmrZMzUtgrLrCDr8wSeFVgsZ@mail.gmail.com","threadId":"26207","inReplyTo":"20110105230334.GB9774@sigill.intra.peff.net","subject":"Re: [BUG?] \"git submodule foreach\" when command is ssh","fromName":"Chris Packham","fromEmail":"judge.packham@gmail.com","sentAt":"2011-01-05T23:22:17Z","receivedAt":"2011-01-05T23:22:17Z","isPatch":false,"sender":{"key":"judge.packham@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155667?v=4"},"body":"On Thu, Jan 6, 2011 at 12:03 PM, Jeff King <peff@peff.net> wrote:\n> On Thu, Jan 06, 2011 at 11:50:58AM +1300, Chris Packham wrote:\n>\n>> Actually this might be a ssh/bash bug (feature?). There is different\n>> behaviour between\n>>\n>>   find . -maxdepth 1 -type d -a ! -name '\\.*' | while read; do echo\n>> $REPLY && ssh localhost ls /; done\n>>\n>> and\n>>\n>>   find . -maxdepth 1 -type d -a ! -name '\\.*' | while read; do echo\n>> $REPLY && ls /; done\n>\n> Ssh will opportunistically eat data on stdin to send to the other side,\n> even though the command on the other side (\"ls\" in this case) will never\n> read it. Because of course ssh has no way of knowing that, and is trying\n> to be an interactive terminal. So it ends up eating some random amount\n> of the data you expected to go to the \"read\" call.\n>\n> You can use the \"-n\" option to suppress it. For example:\n>\n>  $ (echo foo; echo bar) |\n>    while read line; do\n>      echo local $line\n>      ssh host \"echo remote $line\"\n>    done\n>\n> produces:\n>\n>  local foo\n>  remote foo\n>\n> but:\n>\n>  $ (echo foo; echo bar) |\n>    while read line; do\n>      echo local $line\n>      ssh -n host \"echo remote $line\"\n>    done\n>\n> produces:\n>\n>  local foo\n>  remote foo\n>  local bar\n>  remote bar\n>\n> which is what you want.\n>\n> -Peff\n\nThanks that makes sense and adding -n to my ssh invocations solves the problem.\n"}]}