[Patch 1/3] connect.c: add nonstopssh variant to the sshVariant set.

[Patch 1/3] connect.c: add nonstopssh variant to the sshVariant set.

[Randall S. Becker]

From ba4beb8ed0dff67ae6b95692d346adce346e2871 Mon Sep 17 00:00:00 2001
From: "Randall S. Becker" <rsbecker@nexbridge.com>
Date: Fri, 30 Apr 2021 09:56:09 -0400
Subject: [Patch 1/3] connect.c: add nonstopssh variant to the sshVariant set.

This enhancement allows the NonStop SSH subsystem to be supported by
git without the need of a wrapper script. The command arguments for
the platform SSH client in /G/system/zssh/sshoss are constructed based
on optional supplied environment variables SSH2_PROCESS_NAME (system
defined), SSH_SUPPRESS_QUIET, and SSH_SUPPRESS_BANNER.

Signed-off-by: Randall S. Becker <rsbecker@nexbridge.com>
---
 connect.c | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/connect.c b/connect.c
index 40b5c15f81..34e9c4ac33 100644
--- a/connect.c
+++ b/connect.c
@@ -1091,6 +1091,7 @@ enum ssh_variant {
        VARIANT_PLINK,
        VARIANT_PUTTY,
        VARIANT_TORTOISEPLINK,
+       VARIANT_NONSTOPSSH,
 };

 static void override_ssh_variant(enum ssh_variant *ssh_variant)
@@ -1108,6 +1109,8 @@ static void override_ssh_variant(enum ssh_variant *ssh_variant)
                *ssh_variant = VARIANT_PUTTY;
        else if (!strcmp(variant, "tortoiseplink"))
                *ssh_variant = VARIANT_TORTOISEPLINK;
+       else if (!strcmp(variant, "nonstopssh"))
+               *ssh_variant = VARIANT_NONSTOPSSH;
        else if (!strcmp(variant, "simple"))
                *ssh_variant = VARIANT_SIMPLE;
        else
@@ -1156,6 +1159,8 @@ static enum ssh_variant determine_ssh_variant(const char *ssh_command,
        else if (!strcasecmp(variant, "tortoiseplink") ||
                 !strcasecmp(variant, "tortoiseplink.exe"))
                ssh_variant = VARIANT_TORTOISEPLINK;
+       else if (!strcasecmp(variant, "sshoss"))
+               ssh_variant = VARIANT_NONSTOPSSH;

        free(p);
        return ssh_variant;
@@ -1275,6 +1280,7 @@ static void push_ssh_options(struct strvec *args, struct strvec *env,
                case VARIANT_SIMPLE:
                        die(_("ssh variant 'simple' does not support setting port"));
                case VARIANT_SSH:
+               case VARIANT_NONSTOPSSH:
                        strvec_push(args, "-p");
                        break;
                case VARIANT_PLINK:
@@ -1285,6 +1291,17 @@ static void push_ssh_options(struct strvec *args, struct strvec *env,

                strvec_push(args, port);
        }
+
+       if (variant == VARIANT_NONSTOPSSH) {
+               if (!getenv("SSH_SUPPRESS_BANNER"))
+                       strvec_push(args, "-Z");
+               if (!getenv("SSH_SUPPRESS_QUIET"))
+                       strvec_push(args, "-Q");
+               if (getenv("SSH2_PROCESS_NAME")) {
+                       strvec_push(args, "-S");
+                       strvec_push(args, getenv("SSH2_PROCESS_NAME"));
+               }
+       }
 }

 /* Prepare a child_process for use by Git's SSH-tunneled transport. */
--
2.29.2

Re: [Patch 1/3] connect.c: add nonstopssh variant to the sshVariant set.

[Elijah Newren]

On Fri, Apr 30, 2021 at 7:58 AM Randall S. Becker
<rsbecker@nexbridge.com> wrote:
>
> From ba4beb8ed0dff67ae6b95692d346adce346e2871 Mon Sep 17 00:00:00 2001
> From: "Randall S. Becker" <rsbecker@nexbridge.com>
> Date: Fri, 30 Apr 2021 09:56:09 -0400
> Subject: [Patch 1/3] connect.c: add nonstopssh variant to the sshVariant set.
>
> This enhancement allows the NonStop SSH subsystem to be supported by
> git without the need of a wrapper script. The command arguments for
> the platform SSH client in /G/system/zssh/sshoss are constructed based
> on optional supplied environment variables SSH2_PROCESS_NAME (system
> defined), SSH_SUPPRESS_QUIET, and SSH_SUPPRESS_BANNER.

Before introducing 3 new special environment variables, I think this
commit message should explain why you can't just use

GIT_SSH_COMMAND="/G/system/zssh/sshoss -Z -Q -S"

particularly since GIT_SSH_COMMAND was introduced specifically so
people wouldn't have to create wrapper scripts to pass to GIT_SSH.

RE: [Patch 1/3] connect.c: add nonstopssh variant to the sshVariant set.

[Randall S. Becker]

On April 30, 2021 12:25 PM, Elijah Newren wrote:
>On Fri, Apr 30, 2021 at 7:58 AM Randall S. Becker <rsbecker@nexbridge.com>
>wrote:
>>
>> From ba4beb8ed0dff67ae6b95692d346adce346e2871 Mon Sep 17 00:00:00
>2001
>> From: "Randall S. Becker" <rsbecker@nexbridge.com>
>> Date: Fri, 30 Apr 2021 09:56:09 -0400
>> Subject: [Patch 1/3] connect.c: add nonstopssh variant to the sshVariant set.
>>
>> This enhancement allows the NonStop SSH subsystem to be supported by
>> git without the need of a wrapper script. The command arguments for
>> the platform SSH client in /G/system/zssh/sshoss are constructed based
>> on optional supplied environment variables SSH2_PROCESS_NAME (system
>> defined), SSH_SUPPRESS_QUIET, and SSH_SUPPRESS_BANNER.
>
>Before introducing 3 new special environment variables, I think this commit
>message should explain why you can't just use
>
>GIT_SSH_COMMAND="/G/system/zssh/sshoss -Z -Q -S"

No, it would be GIT_SSH_COMMAND='/G/system/zssh/sshoss -Z -Q -S $ZSSH0' and that does not work correctly in the current git code base.

>particularly since GIT_SSH_COMMAND was introduced specifically so people
>wouldn't have to create wrapper scripts to pass to GIT_SSH.

Going back through the archive to why this is needed: https://public-inbox.org/git/008101d4f3db$56c20410$04460c30$@nexbridge.com/

The SSH2_PROCESS_NAME is a system environment variable, not something I am introducing, that specifies the name of the SSH process. It's format is [\NODE.]$NAME, which causes shell to blank it out. A wrapper script is currently mandatory on this platform.

I have been looking for a solution since that thread.

-Randall

Re: [Patch 1/3] connect.c: add nonstopssh variant to the sshVariant set.

[Elijah Newren]

On Fri, Apr 30, 2021 at 9:38 AM Randall S. Becker
<rsbecker@nexbridge.com> wrote:
>
> On April 30, 2021 12:25 PM, Elijah Newren wrote:
> >On Fri, Apr 30, 2021 at 7:58 AM Randall S. Becker <rsbecker@nexbridge.com>
> >wrote:
> >>
> >> From ba4beb8ed0dff67ae6b95692d346adce346e2871 Mon Sep 17 00:00:00
> >2001
> >> From: "Randall S. Becker" <rsbecker@nexbridge.com>
> >> Date: Fri, 30 Apr 2021 09:56:09 -0400
> >> Subject: [Patch 1/3] connect.c: add nonstopssh variant to the sshVariant set.
> >>
> >> This enhancement allows the NonStop SSH subsystem to be supported by
> >> git without the need of a wrapper script. The command arguments for
> >> the platform SSH client in /G/system/zssh/sshoss are constructed based
> >> on optional supplied environment variables SSH2_PROCESS_NAME (system
> >> defined), SSH_SUPPRESS_QUIET, and SSH_SUPPRESS_BANNER.
> >
> >Before introducing 3 new special environment variables, I think this commit
> >message should explain why you can't just use
> >
> >GIT_SSH_COMMAND="/G/system/zssh/sshoss -Z -Q -S"
>
> No, it would be GIT_SSH_COMMAND='/G/system/zssh/sshoss -Z -Q -S $ZSSH0' and that does not work correctly in the current git code base.

Is the problem that $ZSSH0 may contain spaces, or that $ZSSH0 is
expected to change over time and you don't want to have to re-run

GIT_SSH_COMMAND="/G/system/zssh/sshoss -Z -Q -S $ZSSH0"

each time?

> >particularly since GIT_SSH_COMMAND was introduced specifically so people
> >wouldn't have to create wrapper scripts to pass to GIT_SSH.
>
> Going back through the archive to why this is needed: https://public-inbox.org/git/008101d4f3db$56c20410$04460c30$@nexbridge.com/
>
> The SSH2_PROCESS_NAME is a system environment variable, not something I am introducing, that specifies the name of the SSH process. It's format is [\NODE.]$NAME, which causes shell to blank it out. A wrapper script is currently mandatory on this platform.
>
> I have been looking for a solution since that thread.

Ah, so it's the case that $ZSSH0 changes for you, but is set somewhere
by the system and you don't want to have to redefine GIT_SSH_COMMAND
each time you log into some box.

At a minimum, this explanation should be included in the commit
message here, otherwise the problem you're trying to address won't be
understood by reviewers.  It wasn't at all clear to me from your cover
letter or this commit, and I even had trouble parsing it out of the
other thread you linked to.  Only this above paragraph about
SSH2_PROCESS_NAME and its value on your system explain it. (It's still
hard to tell what from your "[\NODE.]$NAME" is literal text and what
is meant to be replaced, though, it might be useful to have an example
of the literal value of SSH2_PROCESS_NAME on some random node in the
explanation as well.)

RE: [Patch 1/3] connect.c: add nonstopssh variant to the sshVariant set.

[Randall S. Becker]

On April 30, 2021 1:17 PM, Elijah Newren wrote:
>On Fri, Apr 30, 2021 at 9:38 AM Randall S. Becker <rsbecker@nexbridge.com>
>wrote:
>>
>> On April 30, 2021 12:25 PM, Elijah Newren wrote:
>> >On Fri, Apr 30, 2021 at 7:58 AM Randall S. Becker
>> ><rsbecker@nexbridge.com>
>> >wrote:
>> >>
>> >> From ba4beb8ed0dff67ae6b95692d346adce346e2871 Mon Sep 17 00:00:00
>> >2001
>> >> From: "Randall S. Becker" <rsbecker@nexbridge.com>
>> >> Date: Fri, 30 Apr 2021 09:56:09 -0400
>> >> Subject: [Patch 1/3] connect.c: add nonstopssh variant to the sshVariant set.
>> >>
>> >> This enhancement allows the NonStop SSH subsystem to be supported
>> >> by git without the need of a wrapper script. The command arguments
>> >> for the platform SSH client in /G/system/zssh/sshoss are
>> >> constructed based on optional supplied environment variables
>> >> SSH2_PROCESS_NAME (system defined), SSH_SUPPRESS_QUIET, and
>SSH_SUPPRESS_BANNER.
>> >
>> >Before introducing 3 new special environment variables, I think this
>> >commit message should explain why you can't just use
>> >
>> >GIT_SSH_COMMAND="/G/system/zssh/sshoss -Z -Q -S"
>>
>> No, it would be GIT_SSH_COMMAND='/G/system/zssh/sshoss -Z -Q -S $ZSSH0'
>and that does not work correctly in the current git code base.
>
>Is the problem that $ZSSH0 may contain spaces, or that $ZSSH0 is expected to
>change over time and you don't want to have to re-run
>
>GIT_SSH_COMMAND="/G/system/zssh/sshoss -Z -Q -S $ZSSH0"
>
>each time?
>
>> >particularly since GIT_SSH_COMMAND was introduced specifically so
>> >people wouldn't have to create wrapper scripts to pass to GIT_SSH.
>>
>> Going back through the archive to why this is needed:
>> https://public-inbox.org/git/008101d4f3db$56c20410$04460c30$@nexbridge
>> .com/
>>
>> The SSH2_PROCESS_NAME is a system environment variable, not something I
>am introducing, that specifies the name of the SSH process. It's format is
>[\NODE.]$NAME, which causes shell to blank it out. A wrapper script is currently
>mandatory on this platform.
>>
>> I have been looking for a solution since that thread.
>
>Ah, so it's the case that $ZSSH0 changes for you, but is set somewhere by the
>system and you don't want to have to redefine GIT_SSH_COMMAND each time
>you log into some box.
>
>At a minimum, this explanation should be included in the commit message here,
>otherwise the problem you're trying to address won't be understood by
>reviewers.  It wasn't at all clear to me from your cover letter or this commit,
>and I even had trouble parsing it out of the other thread you linked to.  Only this
>above paragraph about SSH2_PROCESS_NAME and its value on your system
>explain it. (It's still hard to tell what from your "[\NODE.]$NAME" is literal text
>and what is meant to be replaced, though, it might be useful to have an example
>of the literal value of SSH2_PROCESS_NAME on some random node in the
>explanation as well.)

SSH2_PROCESS_NAME tends not to change much, although it is bound to a set of subnets. Example values are $ZSSH0 or \NODE.$ZSSH0, depending on whether the system admit decides to qualify the name with it's cluster host name, since you could use a different process on a different node. The name may change between repositories - so going to github.com would commonly have a different process name than a local enterprise server. I really would consider putting this in .gitconfig so it can be repository-specific, but I'd prefer to see whether this change has legs before doing that.

There are use cases on the platform where, from the user's perspective, this value may be random. It is set on an inbound SSH session by the server and provided to the shell in that variable. Users will either use the system supplied process (somewhat QoS-related) or will select their own.

Do you have suggestions about the other two settings? I don't like the environment variable approach, but passing switches through git seems pretty heavy to me.

I will do what I can to expand the discussion in the connect.c commit on V2.

-Randall

RE: [Patch 1/3] connect.c: add nonstopssh variant to the sshVariant set.

[Randall S. Becker]

On April 30, 2021 1:32 PM, I wrote:
>Subject: RE: [Patch 1/3] connect.c: add nonstopssh variant to the sshVariant set.
>
>On April 30, 2021 1:17 PM, Elijah Newren wrote:
>>On Fri, Apr 30, 2021 at 9:38 AM Randall S. Becker
>><rsbecker@nexbridge.com>
>>wrote:
>>>
>>> On April 30, 2021 12:25 PM, Elijah Newren wrote:
>>> >On Fri, Apr 30, 2021 at 7:58 AM Randall S. Becker
>>> ><rsbecker@nexbridge.com>
>>> >wrote:
>>> >>
>>> >> From ba4beb8ed0dff67ae6b95692d346adce346e2871 Mon Sep 17
>00:00:00
>>> >2001
>>> >> From: "Randall S. Becker" <rsbecker@nexbridge.com>
>>> >> Date: Fri, 30 Apr 2021 09:56:09 -0400
>>> >> Subject: [Patch 1/3] connect.c: add nonstopssh variant to the sshVariant
>set.
>>> >>
>>> >> This enhancement allows the NonStop SSH subsystem to be supported
>>> >> by git without the need of a wrapper script. The command arguments
>>> >> for the platform SSH client in /G/system/zssh/sshoss are
>>> >> constructed based on optional supplied environment variables
>>> >> SSH2_PROCESS_NAME (system defined), SSH_SUPPRESS_QUIET, and
>>SSH_SUPPRESS_BANNER.
>>> >
>>> >Before introducing 3 new special environment variables, I think this
>>> >commit message should explain why you can't just use
>>> >
>>> >GIT_SSH_COMMAND="/G/system/zssh/sshoss -Z -Q -S"
>>>
>>> No, it would be GIT_SSH_COMMAND='/G/system/zssh/sshoss -Z -Q -S
>$ZSSH0'
>>and that does not work correctly in the current git code base.
>>
>>Is the problem that $ZSSH0 may contain spaces, or that $ZSSH0 is
>>expected to change over time and you don't want to have to re-run
>>
>>GIT_SSH_COMMAND="/G/system/zssh/sshoss -Z -Q -S $ZSSH0"
>>
>>each time?
>>
>>> >particularly since GIT_SSH_COMMAND was introduced specifically so
>>> >people wouldn't have to create wrapper scripts to pass to GIT_SSH.
>>>
>>> Going back through the archive to why this is needed:
>>> https://public-inbox.org/git/008101d4f3db$56c20410$04460c30$@nexbridg
>>> e
>>> .com/
>>>
>>> The SSH2_PROCESS_NAME is a system environment variable, not something
>>> I
>>am introducing, that specifies the name of the SSH process. It's format
>>is [\NODE.]$NAME, which causes shell to blank it out. A wrapper script
>>is currently mandatory on this platform.
>>>
>>> I have been looking for a solution since that thread.
>>
>>Ah, so it's the case that $ZSSH0 changes for you, but is set somewhere
>>by the system and you don't want to have to redefine GIT_SSH_COMMAND
>>each time you log into some box.
>>
>>At a minimum, this explanation should be included in the commit message
>>here, otherwise the problem you're trying to address won't be
>>understood by reviewers.  It wasn't at all clear to me from your cover
>>letter or this commit, and I even had trouble parsing it out of the
>>other thread you linked to.  Only this above paragraph about
>>SSH2_PROCESS_NAME and its value on your system explain it. (It's still
>>hard to tell what from your "[\NODE.]$NAME" is literal text and what is
>>meant to be replaced, though, it might be useful to have an example of
>>the literal value of SSH2_PROCESS_NAME on some random node in the
>>explanation as well.)
>
>SSH2_PROCESS_NAME tends not to change much, although it is bound to a set of
>subnets. Example values are $ZSSH0 or \NODE.$ZSSH0, depending on whether
>the system admit decides to qualify the name with it's cluster host name, since
>you could use a different process on a different node. The name may change
>between repositories - so going to github.com would commonly have a different
>process name than a local enterprise server. I really would consider putting this
>in .gitconfig so it can be repository-specific, but I'd prefer to see whether this
>change has legs before doing that.
>
>There are use cases on the platform where, from the user's perspective, this
>value may be random. It is set on an inbound SSH session by the server and
>provided to the shell in that variable. Users will either use the system supplied
>process (somewhat QoS-related) or will select their own.
>
>Do you have suggestions about the other two settings? I don't like the
>environment variable approach, but passing switches through git seems pretty
>heavy to me.
>
>I will do what I can to expand the discussion in the connect.c commit on V2.

I'm wondering whether this is going to move forward or whether changes are needed. There is no V2 since suppression control of the various parameters used to set up the command appears to be needed.

Thanks,
Randall

RE: [Patch 1/3] connect.c: add nonstopssh variant to the sshVariant set.

[Randall S. Becker]

On May 10, 2021 11:24 AM, I wrote:
>On April 30, 2021 1:32 PM, I wrote:
>>Subject: RE: [Patch 1/3] connect.c: add nonstopssh variant to the sshVariant set.
>>
>>On April 30, 2021 1:17 PM, Elijah Newren wrote:
>>>On Fri, Apr 30, 2021 at 9:38 AM Randall S. Becker
>>><rsbecker@nexbridge.com>
>>>wrote:
>>>>
>>>> On April 30, 2021 12:25 PM, Elijah Newren wrote:
>>>> >On Fri, Apr 30, 2021 at 7:58 AM Randall S. Becker
>>>> ><rsbecker@nexbridge.com>
>>>> >wrote:
>>>> >>
>>>> >> From ba4beb8ed0dff67ae6b95692d346adce346e2871 Mon Sep 17
>>00:00:00
>>>> >2001
>>>> >> From: "Randall S. Becker" <rsbecker@nexbridge.com>
>>>> >> Date: Fri, 30 Apr 2021 09:56:09 -0400
>>>> >> Subject: [Patch 1/3] connect.c: add nonstopssh variant to the
>>>> >> sshVariant
>>set.
>>>> >>
>>>> >> This enhancement allows the NonStop SSH subsystem to be supported
>>>> >> by git without the need of a wrapper script. The command
>>>> >> arguments for the platform SSH client in /G/system/zssh/sshoss
>>>> >> are constructed based on optional supplied environment variables
>>>> >> SSH2_PROCESS_NAME (system defined), SSH_SUPPRESS_QUIET, and
>>>SSH_SUPPRESS_BANNER.
>>>> >
>>>> >Before introducing 3 new special environment variables, I think
>>>> >this commit message should explain why you can't just use
>>>> >
>>>> >GIT_SSH_COMMAND="/G/system/zssh/sshoss -Z -Q -S"
>>>>
>>>> No, it would be GIT_SSH_COMMAND='/G/system/zssh/sshoss -Z -Q -S
>>$ZSSH0'
>>>and that does not work correctly in the current git code base.
>>>
>>>Is the problem that $ZSSH0 may contain spaces, or that $ZSSH0 is
>>>expected to change over time and you don't want to have to re-run
>>>
>>>GIT_SSH_COMMAND="/G/system/zssh/sshoss -Z -Q -S $ZSSH0"
>>>
>>>each time?

I'm looking for a more general solution than what I originally proposed, but still think that we need the variant. With that said: there are multiple command arguments to sshoss that need to be supported and an environment variable for each is obviously not effective. I am thinking that this variant has value. The primary problem is supplying -S $ZSSH0 on the command line causes $ZSSH0 to be resolved as a shell variable. It is not. It is the process name of the SSH stack, which can vary. The current code, if -S $ZSSH0 is supplied, ends up resolving to nothing, so the -S argument eats the URL and the SSH operation fails. The other problem is that sshoss does not support a URL with a port number in it, so that must be resolved explicitly as -p port, but the other variants do not handle this situation, with -S. At the very least, those two parameters (-S, -p) have to be accounted for in the variant, and -Q (suppress local banner) is required or the dialog generally breaks because it comes back on stdout and confuses git. What I am considering is a single NONSTOP_SSH_ARGUMENTS environment variable to contain all other options that may be there today or in future, and have the internal code split the arguments up appropriately.

A bit of background on process names. $ZSSH0 is an example. On my system there is $ZSSGT (external subnets) and $ZSSH1 (internal subnets). There is a wide variety of naming, but they all begin with the annoying $ sign. Escaping the $ does not work consistently, I think because there are varying numbers of shells involved given different circumstances that only impacts the NonStop platform - it's not for lack of trying to get around this.

Looking for guidance on this use case - not expecting this for 2.32, obviously. Currently, we are forced to use a wrapper script, which is not ideal. The -p option has to be embedded in the script so using a GitHub, BitBucket, GitLab, etc., supplied URI does not work correctly. Of course, the script could parse out the :port, but URI parsing seems redundant given the variant mechanism.

Thanks,
Randall

Re: [Patch 1/3] connect.c: add nonstopssh variant to the sshVariant set.

[Junio C Hamano]

"Randall S. Becker" <rsbecker@nexbridge.com> writes:

> The primary
> problem is supplying -S $ZSSH0 on the command line causes $ZSSH0
> to be resolved as a shell variable. It is not.

I think we've heard that one before, and the whole thing sounds like
you are saying that a command line

    $ cmd $ZSSH0

expects ZSSH0 to be a variable and tries to interpolate its value
before passing it to "cmd" while you want "cmd" to see a literal
string that begins with a dollar sign.

And the standard solution to that problem obviously is to tell the
shell that the dollar-sign is not a reference to a variable by
quoting, by using any variant of e.g.

    $ cmd \$ZSSH0
    $ cmd '$ZSSH0'
    $ cmd "\$ZSSH0"

As far as I can tell, the code in connect.c that spawns ssh via
GIT_SSH_COMMAND uses the pretty vanilla run_command() interface,
and that ought to be capable of producing such a command line, so I
am lost as to where the need to have special case comes from.

"cmd" here may be "ssh" but run_command() should not care what exact
command is being invoked.  I am puzzled why a simple quoting like
the following cannot be adjusted for this particular case, for
example:

    $ cat >>.git/config <<\EOF
    [alias]
	cmdtest0 = "!echo ..\\$ZSSH0.."
	cmdtest1 = "!echo ..$ZSSH0.."
    EOF
    $ ZSSH0=foo git cmdtest0
    ..$ZSSH0..
    $ ZSSH0=foo git cmdtest1
    ..foo..

RE: [Patch 1/3] connect.c: add nonstopssh variant to the sshVariant set.

[Randall S. Becker]

On June 4, 2021 3:52 PM, Junio C Hamano wrote:
>"Randall S. Becker" <rsbecker@nexbridge.com> writes:
>> The primary
>> problem is supplying -S $ZSSH0 on the command line causes $ZSSH0 to be
>> resolved as a shell variable. It is not.
>
>I think we've heard that one before, and the whole thing sounds like you are saying that a command line
>
>    $ cmd $ZSSH0
>
>expects ZSSH0 to be a variable and tries to interpolate its value before passing it to "cmd" while you want "cmd" to see a literal
string that
>begins with a dollar sign.
>
>And the standard solution to that problem obviously is to tell the shell that the dollar-sign is not a reference to a variable by
quoting, by
>using any variant of e.g.
>
>    $ cmd \$ZSSH0
>    $ cmd '$ZSSH0'
>    $ cmd "\$ZSSH0"

I'm going to have to retest this, but, when I last tried this, admittedly around git 2.0, what happened was that one level of
escaping the $ worked for ls-remote, but we needed two levels for upload-pack which seemed to have two shells processing the
command. I might be wrong about the specifics (been 4 years), but there was an inconsistency with the number of required escapes.
The single quote did not work for upload-pack at the time. It is entirely possible that the second level indirection happened
because the execution of the sshoss command itself cross over a platform boundary between the POSIX and non-POSIX file systems (it
lives in the non-POSIX side).

>As far as I can tell, the code in connect.c that spawns ssh via GIT_SSH_COMMAND uses the pretty vanilla run_command() interface,
and
>that ought to be capable of producing such a command line, so I am lost as to where the need to have special case comes from.

>"cmd" here may be "ssh" but run_command() should not care what exact command is being invoked.  I am puzzled why a simple quoting
>like the following cannot be adjusted for this particular case, for
>example:
>
>    $ cat >>.git/config <<\EOF
>    [alias]
>	cmdtest0 = "!echo ..\\$ZSSH0.."
>	cmdtest1 = "!echo ..$ZSSH0.."
>    EOF
>    $ ZSSH0=foo git cmdtest0
>    ..$ZSSH0..
>    $ ZSSH0=foo git cmdtest1
>    ..foo..

The multi-level resolution that I experienced is not covered in this situation. Still going to investigate this. I'm working on a
different approach to extend my wrapper script to parse out the port, to supply to sshoss, which is not complaint with the standard
ssh. If I have to stick with that script, there's no point going further on this variant.

RE: [Patch 1/3] connect.c: add nonstopssh variant to the sshVariant set.

[Randall S. Becker]

On June 4, 2021 4:35 PM, I wrote:
>To: 'Junio C Hamano' <gitster@pobox.com>
>Cc: 'Git Mailing List' <git@vger.kernel.org>
>Subject: RE: [Patch 1/3] connect.c: add nonstopssh variant to the sshVariant set.
>
>On June 4, 2021 3:52 PM, Junio C Hamano wrote:
>>"Randall S. Becker" <rsbecker@nexbridge.com> writes:
>>> The primary
>>> problem is supplying -S $ZSSH0 on the command line causes $ZSSH0 to
>>> be resolved as a shell variable. It is not.
>>
>>I think we've heard that one before, and the whole thing sounds like
>>you are saying that a command line
>>
>>    $ cmd $ZSSH0
>>
>>expects ZSSH0 to be a variable and tries to interpolate its value
>>before passing it to "cmd" while you want "cmd" to see a literal string that begins with a dollar sign.
>>
>>And the standard solution to that problem obviously is to tell the
>>shell that the dollar-sign is not a reference to a variable by quoting, by using any variant of e.g.
>>
>>    $ cmd \$ZSSH0
>>    $ cmd '$ZSSH0'
>>    $ cmd "\$ZSSH0"
>
>I'm going to have to retest this, but, when I last tried this, admittedly around git 2.0, what happened was that one level of
escaping the $
>worked for ls-remote, but we needed two levels for upload-pack which seemed to have two shells processing the command. I might be
>wrong about the specifics (been 4 years), but there was an inconsistency with the number of required escapes. The single quote did
not
>work for upload-pack at the time. It is entirely possible that the second level indirection happened because the execution of the
sshoss
>command itself cross over a platform boundary between the POSIX and non-POSIX file systems (it lives in the non-POSIX side).
>
>>As far as I can tell, the code in connect.c that spawns ssh via
>>GIT_SSH_COMMAND uses the pretty vanilla run_command() interface, and that ought to be capable of producing such a command line,
>so I am lost as to where the need to have special case comes from.
>
>>"cmd" here may be "ssh" but run_command() should not care what exact
>>command is being invoked.  I am puzzled why a simple quoting like the
>>following cannot be adjusted for this particular case, for
>>example:
>>
>>    $ cat >>.git/config <<\EOF
>>    [alias]
>>	cmdtest0 = "!echo ..\\$ZSSH0.."
>>	cmdtest1 = "!echo ..$ZSSH0.."
>>    EOF
>>    $ ZSSH0=foo git cmdtest0
>>    ..$ZSSH0..
>>    $ ZSSH0=foo git cmdtest1
>>    ..foo..
>
>The multi-level resolution that I experienced is not covered in this situation. Still going to investigate this. I'm working on a
different
>approach to extend my wrapper script to parse out the port, to supply to sshoss, which is not complaint with the standard ssh. If I
have to
>stick with that script, there's no point going further on this variant.

Without a variant (when simple is used), obviously ports cannot be specified. When using the following URL:

    git clone ssh://git@bitbucket.org:22/myproj/repo.git repo

The arguments appended using the auto-detected ssh variant that end up being passed to the GIT_SSH_COMMAND command string are:

    -o SendEnv=GIT_PROTOCOL -p 22 git@bitbucket.org git-upload-pack '/myproj/repo.git'

which is part of the way there, but the -o SendEnv=GIT_PROTOCOL is OpenSSH specific. There is no such argument for the SSHOSS
program. This becomes somewhat problematic.

Of course, a sufficiently smart wrapper can detect this and strip off the -o SendEnv, which I have working. This just does not seem
like a general solution, leading me back down the nonstopssh variant path.

Sigh.

Randall