{"thread":{"id":"50932","subject":"[BUG] GIT_SSH_COMMAND is not being decomposed","startedAt":"2019-04-13T20:27:53Z","lastAt":"2019-04-16T04:24:53Z","messageCount":10,"participants":["Randall S. Becker","Ævar Arnfjörð Bjarmason","SZEDER Gábor","Andreas Schwab","Johannes Sixt","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"373799","messageId":"000d01d4f237$5cf2dc10$16d89430$@nexbridge.com","threadId":"50932","inReplyTo":null,"subject":"[BUG] GIT_SSH_COMMAND is not being decomposed","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2019-04-13T20:27:44Z","receivedAt":"2019-04-13T20:27:53Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"I am encountering a problem on one of our NonStop platform variants where\nthe GIT_SSH_COMMAND string is not being broken into constituent parts. This\nis causing SSH to not run properly. As background, SSH is not in a standard\nlocation and has non-standard required arguments. This also occurs with\ncore.sshCommand. The situation is:\n\ngit config --global core.sshCommand '/G/system/zssh/sshossz5 -Q'\n\nwhich correctly sets .gitconfig as:\n\n[core]\n        sshCommand = /G/system/zssh/sshossz5 -Q\n\nWhen git is run with GIT_TRACE=true GIT_PACKET_TRACE=true git fetch\n\nWe get the partial trace:\n14:19:56.027088 trace: built-in: git fetch\n14:19:56.029895 trace: run_command: '/G/system/zssh/sshossz5 -Q' -G\nuser@host\n\nThe same trace on our systems that actually do work results in:\n14:19:56.029895 trace: run_command: '/G/system/zssh/sshossz5' '-Q' -G\nuser@host\n\nI need help resolving why this is happening (as in where to look and debug\nthe situation).\n\nUrgently,\nRandall\n\n-- Brief whoami:\nNonStop developer since approximately 211288444200000000\nUNIX developer since approximately 421664400\n-- In my real life, I talk too much.\n\n\n\n"},{"id":"373800","messageId":"874l71fxmg.fsf@evledraar.gmail.com","threadId":"50932","inReplyTo":"000d01d4f237$5cf2dc10$16d89430$@nexbridge.com","subject":"Re: [BUG] GIT_SSH_COMMAND is not being decomposed","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2019-04-13T20:39:35Z","receivedAt":"2019-04-13T20:39:41Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Sat, Apr 13 2019, Randall S. Becker wrote:\n\n> I am encountering a problem on one of our NonStop platform variants where\n> the GIT_SSH_COMMAND string is not being broken into constituent parts. This\n> is causing SSH to not run properly. As background, SSH is not in a standard\n> location and has non-standard required arguments. This also occurs with\n> core.sshCommand. The situation is:\n>\n> git config --global core.sshCommand '/G/system/zssh/sshossz5 -Q'\n>\n> which correctly sets .gitconfig as:\n>\n> [core]\n> sshCommand = /G/system/zssh/sshossz5 -Q\n>\n> When git is run with GIT_TRACE=true GIT_PACKET_TRACE=true git fetch\n>\n> We get the partial trace:\n> 14:19:56.027088 trace: built-in: git fetch\n> 14:19:56.029895 trace: run_command: '/G/system/zssh/sshossz5 -Q' -G\n> user@host\n>\n> The same trace on our systems that actually do work results in:\n> 14:19:56.029895 trace: run_command: '/G/system/zssh/sshossz5' '-Q' -G\n> user@host\n>\n> I need help resolving why this is happening (as in where to look and debug\n> the situation).\n\nThis doesn't seem to be documented *explicitly* (except between the\nlines & inferred), but it's only supported to pass a *command* there,\ni.e. the path of the ssh binary. See the code around get_ssh_command()\nin connect.c. The whole env/config value we look up gets passed as one.\n\nSo if you need arguments you need to create a wrapper script and set ssh\ncommand to that script.\n"},{"id":"373801","messageId":"000e01d4f23b$89d75590$9d8600b0$@nexbridge.com","threadId":"50932","inReplyTo":"874l71fxmg.fsf@evledraar.gmail.com","subject":"RE: [BUG] GIT_SSH_COMMAND is not being decomposed","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2019-04-13T20:57:37Z","receivedAt":"2019-04-13T20:57:47Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On April 13, 2019 16:40, Ævar Arnfjörð Bjarmason wrote:\n> On Sat, Apr 13 2019, Randall S. Becker wrote:\n> \n> > I am encountering a problem on one of our NonStop platform variants\n> > where the GIT_SSH_COMMAND string is not being broken into constituent\n> > parts. This is causing SSH to not run properly. As background, SSH is\n> > not in a standard location and has non-standard required arguments.\n> > This also occurs with core.sshCommand. The situation is:\n> >\n> > git config --global core.sshCommand '/G/system/zssh/sshossz5 -Q'\n> >\n> > which correctly sets .gitconfig as:\n> >\n> > [core]\n> > sshCommand = /G/system/zssh/sshossz5 -Q\n> >\n> > When git is run with GIT_TRACE=true GIT_PACKET_TRACE=true git fetch\n> >\n> > We get the partial trace:\n> > 14:19:56.027088 trace: built-in: git fetch\n> > 14:19:56.029895 trace: run_command: '/G/system/zssh/sshossz5 -Q' -G\n> > user@host\n> >\n> > The same trace on our systems that actually do work results in:\n> > 14:19:56.029895 trace: run_command: '/G/system/zssh/sshossz5' '-Q' -G\n> > user@host\n> >\n> > I need help resolving why this is happening (as in where to look and\n> > debug the situation).\n> \n> This doesn't seem to be documented *explicitly* (except between the lines &\n> inferred), but it's only supported to pass a *command* there, i.e. the path of\n> the ssh binary. See the code around get_ssh_command() in connect.c. The\n> whole env/config value we look up gets passed as one.\n> \n> So if you need arguments you need to create a wrapper script and set ssh\n> command to that script.\n\nThanks. I didn't know that, because this technique worked for years on the older platform variant. My wrapper works fine on the newer system.\n\nWith appreciation,\nRandall\n\n"},{"id":"373803","messageId":"20190413214736.GD15936@szeder.dev","threadId":"50932","inReplyTo":"874l71fxmg.fsf@evledraar.gmail.com","subject":"Re: [BUG] GIT_SSH_COMMAND is not being decomposed","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2019-04-13T21:47:36Z","receivedAt":"2019-04-13T21:47:42Z","isPatch":false,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Sat, Apr 13, 2019 at 10:39:35PM +0200, Ævar Arnfjörð Bjarmason wrote:\n> \n> On Sat, Apr 13 2019, Randall S. Becker wrote:\n> \n> > I am encountering a problem on one of our NonStop platform variants where\n> > the GIT_SSH_COMMAND string is not being broken into constituent parts. This\n> > is causing SSH to not run properly. As background, SSH is not in a standard\n> > location and has non-standard required arguments. This also occurs with\n> > core.sshCommand. The situation is:\n> >\n> > git config --global core.sshCommand '/G/system/zssh/sshossz5 -Q'\n> >\n> > which correctly sets .gitconfig as:\n> >\n> > [core]\n> > sshCommand = /G/system/zssh/sshossz5 -Q\n> >\n> > When git is run with GIT_TRACE=true GIT_PACKET_TRACE=true git fetch\n> >\n> > We get the partial trace:\n> > 14:19:56.027088 trace: built-in: git fetch\n> > 14:19:56.029895 trace: run_command: '/G/system/zssh/sshossz5 -Q' -G\n> > user@host\n> >\n> > The same trace on our systems that actually do work results in:\n> > 14:19:56.029895 trace: run_command: '/G/system/zssh/sshossz5' '-Q' -G\n> > user@host\n> >\n> > I need help resolving why this is happening (as in where to look and debug\n> > the situation).\n> \n> This doesn't seem to be documented *explicitly* (except between the\n> lines & inferred), but it's only supported to pass a *command* there,\n> i.e. the path of the ssh binary.\n\n'man git' it quite explicit about this:\n\n $GIT_SSH_COMMAND takes precedence over $GIT_SSH, and is interpreted\n by the shell, which allows additional arguments to be included.\n $GIT_SSH on the other hand must be just the path to a program (which\n can be a wrapper shell script, if additional arguments are needed).\n\nQuick test shows that the implementation agrees with the\ndocumentation:\n\n $ GIT_TRACE=2 GIT_SSH_COMMAND='/usr/bin/ssh -v' git push -n github\n 23:39:02.048870 git.c:419 trace: built-in: git push -n github\n 23:39:02.060821 run-command.c:643 trace: run_command: unset GIT_PREFIX; '/usr/bin/ssh -v' git@github.com 'git-receive-pack '\\''/szeder/git'\\'''\n OpenSSH_7.2p2 Ubuntu-4ubuntu2.8, OpenSSL 1.0.2g 1 Mar 2016\n debug1: Reading configuration data /home/szeder/.ssh/config\n <... snipt rest of the verbose ssh output ...>\n\nAnd the config setting works, too:\n\n $ GIT_TRACE=2 git -c core.sshCommand='/usr/bin/ssh -v' push -n github\n 23:42:55.277776 git.c:439 trace: built-in: git push -n github\n 23:42:55.285149 run-command.c:663 trace: run_command: unset GIT_CONFIG_PARAMETERS GIT_PREFIX; '/usr/bin/ssh -v' git@github.com 'git-receive-pack '\\''/szeder/git'\\'''\n OpenSSH_7.2p2 Ubuntu-4ubuntu2.8, OpenSSL 1.0.2g 1 Mar 2016\n debug1: Reading configuration data /home/szeder/.ssh/config\n <...>\n\nNote that in both cases the trace shows '/usr/bin/ssh -v', IOW neither\n$GIT_SSH_COMMAND nor 'core.sshCommand' are broken up.\n\nBut this is just an avarage Linux box, so perhaps this is a\nNonStop-specific issue?\n\n\n> See the code around get_ssh_command()\n> in connect.c. The whole env/config value we look up gets passed as one.\n> \n> So if you need arguments you need to create a wrapper script and set ssh\n> command to that script.\n"},{"id":"373821","messageId":"001401d4f2cf$21cafc10$6560f430$@nexbridge.com","threadId":"50932","inReplyTo":"20190413214736.GD15936@szeder.dev","subject":"RE: [BUG] GIT_SSH_COMMAND is not being decomposed","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2019-04-14T14:34:07Z","receivedAt":"2019-04-14T14:34:22Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On April 13, 2019 17:48, SZEDER Gábor wrote:\n> To: Ævar Arnfjörð Bjarmason \n> Cc: Randall S. Becker ; git@vger.kernel.org\n> Subject: Re: [BUG] GIT_SSH_COMMAND is not being decomposed\n> \n> On Sat, Apr 13, 2019 at 10:39:35PM +0200, Ævar Arnfjörð Bjarmason wrote:\n> > On Sat, Apr 13 2019, Randall S. Becker wrote:\n> > > I am encountering a problem on one of our NonStop platform variants\n> > > where the GIT_SSH_COMMAND string is not being broken into\n> > > constituent parts. This is causing SSH to not run properly. As\n> > > background, SSH is not in a standard location and has non-standard\n> > > required arguments. This also occurs with core.sshCommand. The\n> situation is:\n> > >\n> > > git config --global core.sshCommand '/G/system/zssh/sshossz5 -Q'\n> > >\n> > > which correctly sets .gitconfig as:\n> > >\n> > > [core]\n> > > sshCommand = /G/system/zssh/sshossz5 -Q\n> > >\n> > > When git is run with GIT_TRACE=true GIT_PACKET_TRACE=true git fetch\n> > >\n> > > We get the partial trace:\n> > > 14:19:56.027088 trace: built-in: git fetch\n> > > 14:19:56.029895 trace: run_command: '/G/system/zssh/sshossz5 -Q' -G\n> > > user@host\n> > >\n> > > The same trace on our systems that actually do work results in:\n> > > 14:19:56.029895 trace: run_command: '/G/system/zssh/sshossz5' '-Q'\n> > > -G user@host\n> > >\n> > > I need help resolving why this is happening (as in where to look and\n> > > debug the situation).\n> >\n> > This doesn't seem to be documented *explicitly* (except between the\n> > lines & inferred), but it's only supported to pass a *command* there,\n> > i.e. the path of the ssh binary.\n> \n> 'man git' it quite explicit about this:\n> \n> $GIT_SSH_COMMAND takes precedence over $GIT_SSH, and is interpreted\n> by the shell, which allows additional arguments to be included.\n> $GIT_SSH on the other hand must be just the path to a program (which\n> can be a wrapper shell script, if additional arguments are needed).\n> \n> Quick test shows that the implementation agrees with the\n> documentation:\n> \n> $ GIT_TRACE=2 GIT_SSH_COMMAND='/usr/bin/ssh -v' git push -n github\n> 23:39:02.048870 git.c:419 trace: built-in: git push -n github\n> 23:39:02.060821 run-command.c:643 trace: run_command: unset\n> GIT_PREFIX; '/usr/bin/ssh -v' git@github.com 'git-receive-pack\n> '\\''/szeder/git'\\'''\n> OpenSSH_7.2p2 Ubuntu-4ubuntu2.8, OpenSSL 1.0.2g 1 Mar 2016\n> debug1: Reading configuration data /home/szeder/.ssh/config\n> <... snipt rest of the verbose ssh output ...>\n> \n> And the config setting works, too:\n> \n> $ GIT_TRACE=2 git -c core.sshCommand='/usr/bin/ssh -v' push -n github\n> 23:42:55.277776 git.c:439 trace: built-in: git push -n github\n> 23:42:55.285149 run-command.c:663 trace: run_command: unset\n> GIT_CONFIG_PARAMETERS GIT_PREFIX; '/usr/bin/ssh -v' git@github.com 'git-\n> receive-pack '\\''/szeder/git'\\'''\n> OpenSSH_7.2p2 Ubuntu-4ubuntu2.8, OpenSSL 1.0.2g 1 Mar 2016\n> debug1: Reading configuration data /home/szeder/.ssh/config\n> <...>\n> \n> Note that in both cases the trace shows '/usr/bin/ssh -v', IOW neither\n> $GIT_SSH_COMMAND nor 'core.sshCommand' are broken up.\n> \n> But this is just an avarage Linux box, so perhaps this is a NonStop-specific\n> issue?\n\nI'm sure it is a NonStop issue. It is interesting that 2.21.0 broke the string apart on the older NonStop variant and not the newer one. But looking at the code, I can't imagine how the string was broken up into parts. Makes no sense at all with xstrdup() and argv_array_push(). \n\n> > See the code around get_ssh_command()\n> > in connect.c. The whole env/config value we look up gets passed as one.\n> >\n> > So if you need arguments you need to create a wrapper script and set\n> > ssh command to that script.\n\nGoing forward, I'm going to use (and strongly recommend) a wrapper on both NonStop variants. It's the right way to go, and not only a trivial script but makes configuring communication with upstream servers much easier (there are potentially multiple TCP/IP stacks and multiple SSH d databases available that need to be selected on the sshoss command line). Managing all that in one place is easier than having each user worry about it changing over time.\n\nThanks again,\nRandall\n\n"},{"id":"373891","messageId":"004d01d4f3c0$3ff358d0$bfda0a70$@nexbridge.com","threadId":"50932","inReplyTo":"20190413214736.GD15936@szeder.dev","subject":"RE: [BUG] GIT_SSH_COMMAND is not being decomposed","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2019-04-15T19:20:07Z","receivedAt":"2019-04-15T19:20:24Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On April 13, 2019 17:48, SZEDER Gábor wrote:\n> On Sat, Apr 13, 2019 at 10:39:35PM +0200, Ævar Arnfjörð Bjarmason wrote:\n> > On Sat, Apr 13 2019, Randall S. Becker wrote:\n> >\n> > > I am encountering a problem on one of our NonStop platform variants\n> > > where the GIT_SSH_COMMAND string is not being broken into\n> > > constituent parts. This is causing SSH to not run properly. As\n> > > background, SSH is not in a standard location and has non-standard\n> > > required arguments. This also occurs with core.sshCommand. The\n> situation is:\n> > >\n> > > git config --global core.sshCommand '/G/system/zssh/sshossz5 -Q'\n> > >\n> > > which correctly sets .gitconfig as:\n> > >\n> > > [core]\n> > > sshCommand = /G/system/zssh/sshossz5 -Q\n> > >\n> > > When git is run with GIT_TRACE=true GIT_PACKET_TRACE=true git fetch\n> > >\n> > > We get the partial trace:\n> > > 14:19:56.027088 trace: built-in: git fetch\n> > > 14:19:56.029895 trace: run_command: '/G/system/zssh/sshossz5 -Q' -G\n> > > user@host\n> > >\n> > > The same trace on our systems that actually do work results in:\n> > > 14:19:56.029895 trace: run_command: '/G/system/zssh/sshossz5' '-Q'\n> > > -G user@host\n> > >\n> > > I need help resolving why this is happening (as in where to look and\n> > > debug the situation).\n> >\n> > This doesn't seem to be documented *explicitly* (except between the\n> > lines & inferred), but it's only supported to pass a *command* there,\n> > i.e. the path of the ssh binary.\n> \n> 'man git' it quite explicit about this:\n> \n> $GIT_SSH_COMMAND takes precedence over $GIT_SSH, and is interpreted\n> by the shell, which allows additional arguments to be included.\n> $GIT_SSH on the other hand must be just the path to a program (which\n> can be a wrapper shell script, if additional arguments are needed).\n> \n> Quick test shows that the implementation agrees with the\n> documentation:\n> \n> $ GIT_TRACE=2 GIT_SSH_COMMAND='/usr/bin/ssh -v' git push -n github\n> 23:39:02.048870 git.c:419 trace: built-in: git push -n github\n> 23:39:02.060821 run-command.c:643 trace: run_command: unset\n> GIT_PREFIX; '/usr/bin/ssh -v' git@github.com 'git-receive-pack\n> '\\''/szeder/git'\\'''\n> OpenSSH_7.2p2 Ubuntu-4ubuntu2.8, OpenSSL 1.0.2g 1 Mar 2016\n> debug1: Reading configuration data /home/szeder/.ssh/config\n> <... snipt rest of the verbose ssh output ...>\n> \n> And the config setting works, too:\n> \n> $ GIT_TRACE=2 git -c core.sshCommand='/usr/bin/ssh -v' push -n github\n> 23:42:55.277776 git.c:439 trace: built-in: git push -n github\n> 23:42:55.285149 run-command.c:663 trace: run_command: unset\n> GIT_CONFIG_PARAMETERS GIT_PREFIX; '/usr/bin/ssh -v' git@github.com\n> 'git-receive-pack '\\''/szeder/git'\\'''\n> OpenSSH_7.2p2 Ubuntu-4ubuntu2.8, OpenSSL 1.0.2g 1 Mar 2016\n> debug1: Reading configuration data /home/szeder/.ssh/config\n> <...>\n> \n> Note that in both cases the trace shows '/usr/bin/ssh -v', IOW neither\n> $GIT_SSH_COMMAND nor 'core.sshCommand' are broken up.\n> \n> But this is just an avarage Linux box, so perhaps this is a NonStop-specific\n> issue?\n> \n> \n> > See the code around get_ssh_command()\n> > in connect.c. The whole env/config value we look up gets passed as one.\n> >\n> > So if you need arguments you need to create a wrapper script and set\n> > ssh command to that script.\n\nWhat is strange is that GIT_SSH_COMMAND='/usr/bin/ssh -v' should not execute if we are just looking at an object path. It should be broken into '/usr/bin/ssh' and '-v' otherwise spawn* or exec* will not execute it. I'm still trying to understand why I can successfully do things like the following:\n\n$ GIT_SSH_COMMAND=\"ssh -i ~/.ssh/myid\" git fetch\n\non virtually any platform at my disposal (Windows, Ubuntu, MacOS, the older NonStop variant), and have that work with no problem. Somewhere after get_ssh_command(), the command is being interpreted it its parts either as a shell or something else (still trying to find that).\n\n\n"},{"id":"373910","messageId":"87ef63ezt9.fsf@igel.home","threadId":"50932","inReplyTo":"004d01d4f3c0$3ff358d0$bfda0a70$@nexbridge.com","subject":"Re: [BUG] GIT_SSH_COMMAND is not being decomposed","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2019-04-15T21:14:26Z","receivedAt":"2019-04-15T21:14:34Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"On Apr 15 2019, \"Randall S. Becker\" wrote:\n\n> on virtually any platform at my disposal (Windows, Ubuntu, MacOS, the\n> older NonStop variant), and have that work with no problem. Somewhere\n> after get_ssh_command(), the command is being interpreted it its parts\n> either as a shell or something else (still trying to find that).\n\nSee run-command.c:prepare_shell_cmd, if the command contains shell meta\ncharacters it is passed to sh -c without further quoting.\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1\n\"And now for something completely different.\"\n"},{"id":"373912","messageId":"275443bc-ec87-09a0-d4c5-cc3bb86be105@kdbg.org","threadId":"50932","inReplyTo":"004d01d4f3c0$3ff358d0$bfda0a70$@nexbridge.com","subject":"Re: [BUG] GIT_SSH_COMMAND is not being decomposed","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2019-04-15T21:30:40Z","receivedAt":"2019-04-15T21:30:46Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 15.04.19 um 21:20 schrieb Randall S. Becker:\n> What is strange is that GIT_SSH_COMMAND='/usr/bin/ssh -v' should not\n> execute if we are just looking at an object path. It should be broken\n> into '/usr/bin/ssh' and '-v' otherwise spawn* or exec* will not\n> execute it. I'm still trying to understand why I can successfully do\n> things like the following:>\n> $ GIT_SSH_COMMAND=\"ssh -i ~/.ssh/myid\" git fetch\n> \n> on virtually any platform at my disposal (Windows, Ubuntu, MacOS, the\n> older NonStop variant), and have that work with no problem. Somewhere\n> after get_ssh_command(), the command is being interpreted it its\n> parts either as a shell or something else (still trying to find\n> that).\nHave a look at fill_ssh_args() and determine_ssh_variant() in connect.c.\nQuite a lot is going on there. I don't see immediately why it doesn't\nfollow the usual logic in your case, though.\n\n-- Hannes\n"},{"id":"373925","messageId":"008101d4f3db$56c20410$04460c30$@nexbridge.com","threadId":"50932","inReplyTo":"87ef63ezt9.fsf@igel.home","subject":"RE: [BUG] GIT_SSH_COMMAND is not being decomposed","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2019-04-15T22:34:02Z","receivedAt":"2019-04-15T22:34:17Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On April 15, 2019 17:14, Andreas Schwab wrote:\n> On Apr 15 2019, \"Randall S. Becker\" wrote:\n> \n> > on virtually any platform at my disposal (Windows, Ubuntu, MacOS, the\n> > older NonStop variant), and have that work with no problem. Somewhere\n> > after get_ssh_command(), the command is being interpreted it its parts\n> > either as a shell or something else (still trying to find that).\n> \n> See run-command.c:prepare_shell_cmd, if the command contains shell meta\n> characters it is passed to sh -c without further quoting.\n> \n> Andreas.\n\nWell crap. That explains far too much about what is happening. 😊. One of the special parameters is specified as -S \\$ZSSH2 (example, referring to the process name - which begin with $ and have to be escaped with \\). This obviously triggers the alternate path and has been problematic. On the older systems, we found fewer (a.k.a just about none) uses of this parameter, so never encountered it. On the newer systems, virtually everyone is using -S. Ergo, behavioural differences. That explains a whole lot of why we need a wrapper script. Thanks for the pointer to the strcspn() reference. I can stop obsessing about this (thanks too Johannes, Szeder, Ævar) for the help.\n\nAs a suggestion, with people who know how to escape stuff properly (or not), perhaps we can select the alternate behaviour explicitly using a core.sshIgnoreEscape=true/false option. Thoughts on that?\n\nRegards,\nRandall\n\n"},{"id":"373928","messageId":"xmqqsguipofi.fsf@gitster-ct.c.googlers.com","threadId":"50932","inReplyTo":"008101d4f3db$56c20410$04460c30$@nexbridge.com","subject":"Re: [BUG] GIT_SSH_COMMAND is not being decomposed","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-04-16T04:24:49Z","receivedAt":"2019-04-16T04:24:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Randall S. Becker\" writes:\n\n> As a suggestion, with people who know how to escape stuff properly\n> (or not), perhaps we can select the alternate behaviour explicitly\n> using a core.sshIgnoreEscape=true/false option. Thoughts on that?\n\nThe semantics of prepare_shell_cmd() is, regardless of any \"funny\ncharacters\" on the command line, the spawned command MUST behave AS\nIF it was run via the shell. The strcspn() trick is there merely as\na low-level optimization so that we do not have to say\n\n\tsh -c a-single-token\n\nwhich would be exactly the same as running\n\n\ta-single-token\n\nThe most typical use of that strcspn() trick is to ensure that\n\n\tGIT_SSH_COMMAND=\"the-command and its arguments\"\n\nwould not attempt to run a command with a long and funny name\n\"the-command and its arguments\" somewhere on the $PATH without any\nparameter, and instead run\n\n\tsh -c \"the-command and its arguments\"\n\ni.e. run the \"the-command\" with three parameters (and perhaps more\nbuilt-in parameters prepared by the caller in the ssh connection\ncodepath).\n"}]}