Add support for GNU lsh to ssh.py

...and of course we'll obey BZR_SSH if it's defined.

If we want to support arbitrary "BZR_SSH" then we need to re-think how we do things.

For one, people expect to be able to give an absolute path to an executable, and possibly arguments to that executable. And, of course, spaces in the path conflict with arguments... ENV vars aren't particularly well delimited...

If we just want to add 'lsh' as a known vendor, that should be much easier. Probably look at the 'SSHCorpSubprocessVendor', since that code only seems to add a single '-x' to the command line.

I also guess it means we need to change the auto-detect code, so that it tries 'ssh -V' as well as 'lsh -V', etc.

One other possibility, is that we have a GenericSubprocessVendor, which doesn't try to do anything 'safe' like closing port forwardings, and just spawns the command. Then the code that does detection can find that it doesn't know what '/usr/bin/rsh' is, and just use the generic path.

There's another bug pointing out that BZR_SSH doesn't actually (?)
accept the command name, it just says what type of ssh it is, and I do
think this is a bug.

Also, presumably SSH is something people want to change fairly rarely,
so perhaps it should be a configuration variable. That would be
useful if it can be set per location and it would also allow for
specifying extra options as to what type of process it is.

--
Martin <http://launchpad.net/~mbp/>

Added "lsh" as a valid value for BZR_SSH; seems to work but I'm going to do a bit more black-box testing before I call it done.

As far as auto-detecting goes, The binary installed by the Ubuntu lsh package is 'lsh' not 'ssh'. Can I assume that's what lsh will always be called and look for it if ssh isn't found, or should I also check the version string returned by ssh to see if it's lsh?

I can't find the bug Martin refers to about BZR_SSH not accepting an arbitrary command name. Certainly that's not a trivial change, since it looks like the different versions of ssh take different arguments for specifying things like the user name. It would be more straightforward if we did add it as a configuration variable rather than in BZR_SSH.

> As far as auto-detecting goes, The binary installed by the Ubuntu lsh package is 'lsh' not 'ssh'.

This is a good question, if it's ever different I'd prefer you used a magic config value like "gnussh" rather than "lsh" so as not to confuse things. Note, because of the below, using "lsh" in BZR_SSH would still work.

> I can't find the bug Martin refers to about BZR_SSH not accepting an arbitrary command name.

It's bug 176292 and landed back before 2.1 was released.

I looked through the lsh manual and it consistently uses the terms "lsh" and GNU lsh", including in the usage examples. It describes lsh as an implementation of the SSH protocol, rather that a version of the ssh program. Therefore I think "lsh" is probably the best (i.e. least potentially confusing) magic string, and I'll leave it that way unless I hear otherwise.

bzr will of course detect if the ssh on the system is actually lsh.

Okay, great. Anyway, this conversation could be happening in the merge proposal, and your branch looks good so go to lp:~mgordon/bzr/374700-Add-gnu-lsh-support and hit "Propose for merging" already!

It would be nice also to add a configuration option to set this, not
just an environment variable.
--
Martin

Should I create a new case for the configuration option or just continue with this case?

On 29 September 2010 10:40, Matthew Gordon <email address hidden> wrote:
> Should I create a new case for the configuration option or just continue
> with this case?

That can be a separate bug, sorry I should have said that.\

--
Martin