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.
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 'SSHCorpSubproc essVendor' , 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 GenericSubproce ssVendor, 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.