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

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:

quoted

On Fri, Apr 30, 2021 at 9:38 AM Randall S. Becker
[off-list ref]
wrote:

quoted

On April 30, 2021 12:25 PM, Elijah Newren wrote:

quoted

On Fri, Apr 30, 2021 at 7:58 AM Randall S. Becker
[off-list ref]
wrote:

quoted

From ba4beb8ed0dff67ae6b95692d346adce346e2871 Mon Sep 17

00:00:00

quoted

quoted

quoted

2001

quoted

From: "Randall S. Becker" <redacted>
Date: Fri, 30 Apr 2021 09:56:09 -0400
Subject: [Patch 1/3] connect.c: add nonstopssh variant to the sshVariant

set.

quoted

quoted

quoted

quoted

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.

quoted

quoted

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'

quoted

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?

quoted

quoted

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.

quoted

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