Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #181404 +++ I would like to be able to automatically execute a number of commands in the remote shell to setup the environment before my application is launched by CDT remote application launcher. A thread with a detailed discussion on this topic is on the target management mailing list and starts here: http://www.eclipse.org/newsportal/article.php?id=116&group=eclipse.dsdp.tm#116 Thanks, Sander
This sounds like a nice enhancement request. Comments?
(In reply to comment #1) > This sounds like a nice enhancement request. > Comments? > I agree. A good candidate for the next release.
This makes sense to me, especially for things like initializing an environment.
OK. I think in the simplest case, this would be a single text box allowing to enter a single command to execute at the remote side at shell startup. This could then run a script to do more initializations (e.g. source myScript.sh). Alternatively, a full editor could be opened to edit the script on the local side. Preferences?
I would prefer the simplest and most transparant implementation. Hence, a text box for one single command would do the job. In fact, I can not think of any realistic Use Case that would require more than that. Thanks, Sander (In reply to comment #4) > OK. > I think in the simplest case, this would be a single text box allowing to > enter a single command to execute at the remote side at shell startup. This > could then run a script to do more initializations (e.g. source myScript.sh). > Alternatively, a full editor could be opened to edit the script on the local > side. > Preferences?
Well, the problem with a single command like "source envFile.sh" is that it will work only on those particular hosts where envFile.sh exists in a given place. Thus it is not easily team shareable. We intend to foster team sharing of connections in RSE over time. Thus having the full script of commands to be executed managed by RSE persistence improves team sharing. The question is, is this necessary and do we need it for 2.0 or should we go with a simple solution for now and enhance it for a more versatile UI after 2.0?
The biggest advantage of the "single command solution" is the transparancy, i.e. it is obvious what the remote launcher will try to do and an error message like "envFile.sh not found" on the remote host is very clear. Could you comment on how the "team shareable solution" would affect this transparancy? Thanks, Sander
Trying to get this done for RC2. FYI, a similar request to generalize this for all shells is tracked in bug #181402.
Will try for RC3
Not for 2.0 - sorry, ran out of time. Note though, that extenders can add this feature to their own variant of remotecdt launch easily.
(In reply to comment #10) > Not for 2.0 - sorry, ran out of time. Note though, that extenders can add this > feature to their own variant of remotecdt launch easily. > Does this enhancement go into 3.0? Thanks, Sander
I need very similar capabilities for setting env variables but with slightly different use case. In my case, I need to add a different path value to LD_LIBRARY_PATH depending on which executable is getting invoked. This is to ensure that multiple versions of the same executable binary can be invoked but it doesn't load the incompatible version of its corresponding library. So I cannot add all the library paths for the various executable binaries in one shot. One solution is to write a wrapper for each executable version as shown below: #!/bin/sh # foo-1.1 LD_LIBRARY_PATH="/usr/lib/foo1.1:$LD_LIBRARY_PATH" export LD_LIBRARY_PATH exec foo-1.1 "$0" ${1+"$@"} #!/bin/sh # foo-1.2 LD_LIBRARY_PATH="/usr/lib/foo1.2:$LD_LIBRARY_PATH" export LD_LIBRARY_PATH exec foo-1.2 "$0" ${1+"$@"} However, this requires me to first create a wrapper, save it on the remote host in appropriate location and then invoke the wrapper instead of an executable. On the other hand, if RSE provided a mechanism to set environment variables on the remote host which are valid for the context of command invocation only, it would be very useful.
I propose adding a single "Commands to execute before application" field to the RemoteCDT tab. This single command can then be a shellscript ("source foo.csh"), (". bar.sh") to perform all necessary steps. The Launch Delegate should just take the contents of this additional field, and print it into the open Shell that it already has, just before it launches the application. It sounds like a fairly simple but really useful enhancement request. Drasch could you have a look at this?
Created attachment 121082 [details] Mockup of modified remote C main tab Should it be a text field or text area? What would you prefer?
Created attachment 121414 [details] solution
Patch is checked in. (In reply to comment #15) > Created an attachment (id=121414) [details] > solution
