Re: Advise request on adding a new SSH variant

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Randall,
some drive-by comments..

On 26/04/2021 16:08, Randall S. Becker wrote:
> Hi Team,
>
> I am getting a bunch of requests from my team (and customers) to make SSH
> configuration easier on the NonStop platform. 
> We are currently using a
> wrapper script to drive the variant of SSH on the platform but that is not
> convenient for many people. 
> I would like to add an ssh.Variant called
> "nonstopssh", or something like that, which takes a few extra parameters.
> -Q (quiet), -Z (don't display the banner), -p port (obvious but typically
> required), -S (a system process name). 
https://git-scm.com/docs/git-config#Documentation/git-config.txt-sshvariant

Sounds sensible to me. Maybe also look at past issues that
Git-for-Windows had with folks having too much prior choice (plink,
putty, tortoiseplink). May need more clarity in the docs ;-)

> The code in connect.c looks pretty
> straight forward, but I'm wondering about the best way to pass in a process
> name (it would be something like "$ZSSHX" - usually an environment variable
> "SSH2_PROCESS_NAME"). 
Hopefully others can chime in.. Maybe see discussion at
<pull.913.git.1616511182942.gitgitgadget@xxxxxxxxx> about $ARG variable.
> The program name for SSH, I assume, could come from
> GIT_SSH_COMMAND (typically "/G/system/zssh/sshoss", or I could force it if
> not supplied). 
https://git-scm.com/docs/git-config#Documentation/git-config.txt-coresshCommand
> I'm also wondering about controls for the -Q and -Z
> parameters.
> Should I just use the environment for this and build up args or
> is there a more appropriate way of managing these values?

>
> Thanks in advance,
> Randall
>
> -- Brief whoami:
> NonStop developer since approximately 211288444200000000
> UNIX developer since approximately 421664400
> -- In my real life, I talk too much.
>
>
I was also thinking that the lack of replies maybe links to the "Pain
points in Git's patch flow" thread <YHaIBvl6Mf7ztJB3@xxxxxxxxxx> 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)

--
Philip



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux