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@xxxxxxxxxxxxx> >>wrote: >>> >>> On April 30, 2021 12:25 PM, Elijah Newren wrote: >>> >On Fri, Apr 30, 2021 at 7:58 AM Randall S. Becker >>> ><rsbecker@xxxxxxxxxxxxx> >>> >wrote: >>> >> >>> >> From ba4beb8ed0dff67ae6b95692d346adce346e2871 Mon Sep 17 >00:00:00 >>> >2001 >>> >> From: "Randall S. Becker" <rsbecker@xxxxxxxxxxxxx> >>> >> 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
