Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [dsdp-tm-dev] "Run a command" functionality

Hi all,


Here's my point of view:


- 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.


- 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?

- An agent can be simple, eg the FISH protocol in Perl, see


- 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

- For Performance, the API should be capable of executing multiple commands on a single shannel (like RemoteCommandOperation does today) – see also


- Related to “run a command” API work, also consider these bugs:

- need to get PID from running command

- environment getting and setting are not supported by SSHShellService

- 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 “” 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.





Martin Oberhuber, SMTS / Product Architect – Development Tools, Wind River

direct +43.662.457915.85  fax +43.662.457915.6


Back to the top