Re: [dsdp-tm-dev] "Run a command" functionality

[Vladimir Prus <vladimir@xxxxxxxxxxxxxxxx>]

On Monday, June 27, 2011 13:04:30 Oberhuber, Martin wrote:

Hi Martin,

thanks for the response.

> - From consumer point of view, running a command while getting output and
> exit value is a very important capability which enables many other uses.
> Would also help a lot in the SSH Processes implementation :) Since
> consumers want this to work on any connection, crafting API for this
> absolutely makes sense.
> 
> - Same API should be usable when there's an agent on the remote (such as
> TCF or dstore) or when there's no agent.

Definitely.

> - Main concern is about implementation - given the limitations of SSH /
> Telnet, it looks like the only "clean" way of avoiding PTY issues and
> returning an exit code is having an agent on the remote. So looking at the
> bigger picture, the preferred approach would be using an agent (eg TCF
> which already has API too). Vladimir, have you explored options of
> installing an agent / proxy on the remote?

I don't think this is generally an good option for us. While we do ship
some target-side code as part of our product, we don't necessary ship
ready-to-use sysroot, and should be prepared to work with that
is already on the target. Custom agent does not seem like something
a customer would be happy to install.

> 
> - An agent can be simple, eg the FISH protocol in Perl, see
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=213438#c3
> 
> 
> 
> - If we do go down the path of interacting with a Shell on the remote via
> SSH / Telnet / any other Shell channel (which I do think makes sense,
> since it's a very common setup):
> 
> - An API for plugging in the Shell interpreter code makes sense. Similar to
> what James did in CDT - perhaps we could join forces with CDT
> 
> - Eventually being able to auto-detect the type of shell on the remote
> would make sense... though initially, static config would be OK too (see
> also https://bugs.eclipse.org/bugs/show_bug.cgi?id=244404)
> 
> - For Performance, the API should be capable of executing multiple commands
> on a single shannel (like RemoteCommandOperation does today) - see also
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=175300
> 
> 
> 
> - Related to "run a command" API work, also consider these bugs:
> 
> - https://bugs.eclipse.org/bugs/show_bug.cgi?id=161774 need to get PID from
> running command
> 
> - https://bugs.eclipse.org/bugs/show_bug.cgi?id=162018 environment getting
> and setting are not supported by SSHShellService
> 
> - https://bugs.eclipse.org/bugs/show_bug.cgi?id=244132 Request API to send
> signals to IHostShell
> 
> 
> 
> 
> 
> Vladimir, I'm fine if you pursue work towards a "run a command" API in RSE,
> when you're sure you need it (and can't use an agent on the remote).
> 
> Filing an API Bug for further discussion would be the right next step, and
> discussions should consider James' work in CDT.
> 
> 
> 
> Since every Eclipse API should have an exemplary client in open source too,
> I'd recommend rewriting the "LinuxShellProcessService.java" implementation
> as the exemplary client. So ideally bug 175300 should be fixed as a
> by-product of this work and the code should become cleaner.

thanks for the guidance, as well as providing related issues that must
be considered. Now that I understand this feature is in general
welcome, I'll work with my management to schedule actual work on this.

Thanks,

-- 
Vladimir Prus
CodeSourcery / Mentor Graphics
+7 (812) 677-68-40