RE: Advise request on adding a new SSH variant
Randall S. Becker, Managing Director, Nexbridge Inc. +1.416.984.9826
Show 17 quoted lines
>-----Original Message-----
>From: Junio C Hamano <gitster@pobox.com>
>Sent: May 4, 2021 8:49 PM
>To: Philip Oakley <philipoakley@iee.email>
>Cc: Randall S. Becker <rsbecker@nexbridge.com>; git@vger.kernel.org
>Subject: Re: Advise request on adding a new SSH variant
>
>Philip Oakley <philipoakley@iee.email> writes:
>
>> I was also thinking that the lack of replies maybe links to the "Pain
>> points in Git's patch flow" thread <YHaIBvl6Mf7ztJB3@google.com>
>> whereby it's all about the proposed patch, rather than thoughts about
>> a potential patch.
>> (Sort of like the philosophy of science [method] that ignores opinion,
>> and demands evidence)
>
>Actually, the initial message on this matter from Randall came in the patch
><011e01d73dd0$ec141530$c43c3f90$@nexbridge.com>, so if it were truly "it's
>all about the proposed patch, rather than thoughts about a potential
>would have gained much more responses.
>
>Other than I didn't have time, the reason I didn't respond was that the
>and notation used there were a bit too foreign to me to decide from where
>start asking questions. It wasn't clear what '$ZSSHX' meant (is it the
>environment variable whose name is ZSSHX, or is it literally a name with
>in it and is the issue being addressed that it is too cumbersome to quote
>properly in value of the GIT_SSH_COMMAND environment variable?) for
>example. And after reading the message you are responding to twice, I do
Show 8 quoted lines
>quite get what problem we are trying to solve. Especially since
>
> 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.
>
>in <012601d73ddf$3d0cf660$b726e320$@nexbridge.com> sounded like we
>have a fairly clearly demonstratable problem (i.e. the handling of the
>line given via GIT_SSH_COMMAND is somehow broken). The details of "does not
>work correctly in the current code base" is not yet disclosed but it
>would be possible to tease it out and solve the issue in a more direct way.
>yet the solution presented in the three-patch series looked like it was
>sidestepping the entire issue and adding a special case for NonStop without
>having to touch GIT_SSH_COMMAND at all (presumably leaving it still
"broken").
Were it not for the response in thread https://public-inbox.org/git/008101d4f3db$56c20410$04460c30$@nexbridge.com, I would take a 100% agreement position. But it sounded like the problem was platform-related so would not be fixed, thus the variant that avoids the issue.
By running a shell if GIT_SSH_COMMAND is not a simple path, with potentially multiple levels of escapes of the $ required, depending on the circumstances of how the command is run, I would agree completely. However, with a variant, as described in how the variant operates (from my interpretation), it seems like the approach of the patch is correct by avoiding shell variable resolution on an exotic platform rather than solving an otherwise situation that would not be likely to occur anywhere else.
The environment variable is named SSH2_PROCESS_NAME and contains a value starting with $ - making a shell interpret it if a shell is started. $ZSSH0 is a typical name used, but the value varies from system to system, except for the $ that is mandatory to designate the name of a process. There was no UNIX variant in 1978 when the platform was created, so that prefix character was chosen. It won't change in the foreseeable future, for the expected lifespan of the platform.
With all of the above, as long as there is a potential solution, I'm up for it, but let me know how you would like it to look and I'll try to make it work.
-Randall "who did not himself come up with the NonStop naming structure" and "who has no control over how NonStop SSH interprets anything whatsoever" Becker.
Randall S. Becker
