On 8 Dec 2015, at 21:09, Rob Stryker wrote:
Well, they run 'bash' basically, which then has a full path, and then feed further commands into the bash command. But I don't think running bash is a solution thats appropriate for us over in cdk / vagrant.
I still think our tools should be able to handle if the command isn't on the path.
if it is not on the path users should be asked to point to it.
There's no reason to make that assumption when to work around it is so simple. We simply search the path, which finds 95% of the usecases in a very very quick time. And in the event it's not on the path, we do the which/where, and this command responds almost instantly.
which searches the path and where is a control structure so I do not follow what difference that makes.
We've already noticed that Mac seems to generate a different path based on if you use the .app shortcut or from a terminal.
Yes, same for linux and windows afaik. They behave very similar here - just that on linux we (devs not users) tend to use command line to start things with.
And windows users often install things like putty without explicitly putting them on the path since they're used to using the binaries directly. There seem to be many ways in which the path might be incomplete, and it's definitely worth our while to use every mechanism available to find them, to help our users and make our tools work OOTB.
I don't grok why you are talking about putty here.
For Vagrant users are required to have it on the path to use it properly on windows afaik. So I don't understand why we can't rely on that too.
Anyway, again, we only run the search logic once per workspace session. In 95% of the cases it responds extremely fast. In the event the binary isn't found on the path, the simple which/where runs, and also returns extremely quickly... and this is done only once per workspace. I can't even notice a delay honestly.
Again, search path == run which so I'm not following why this is relevant ?
And I definitely do not like that search logic like this is done once per workspace session. Should be done on each run. Eclipse is a long running thing and unless operations are extremely expensive (like a remote/possible blocking call) we should do them dynamically instead of statically.
/max
On 12/08/2015 03:00 PM, Max Rydahl Andersen wrote:
Rob,
Is the Tty issue not separate from the way they use to locate the right way to run.
I.e. They assume user has vagrant on path. Removing all need for doing custom which/where etc.
/max
http://about.me/maxandersenOn 08 Dec 2015, at 20:34, Gorkem Ercan <gercan@redhat.com <mailto:gercan@redhat.com>> wrote:
I guess you can deal with /dev/tty. Perhaps something like "sh -l less >/dev/tty" would work (I have not tried it though)
On Tue, Dec 8, 2015 at 1:40 PM, Rob Stryker <rob.stryker@jboss.com <mailto:rob.stryker@jboss.com>> wrote:
OK, so, tl;dr is it seems you're using Debug.exec(etc) to launch
the command, in this case bash, which then gives you an
IProcess. You feed further input into the IProcess to get the
desired result, and I'm assuming you wire in the console support
on your own via stream listeners.So you're not using any of org.eclipse.tm.terminal stuff.
I've played with your utility class
https://github.com/gorkem/thym/blob/use_cli/plugins/org.eclipse.thym.core/src/org/eclipse/thym/core/internal/util/ExternalProcessUtility.java
and it also seems to not function if the process being run is
expecting the caller to be a TTY terminal (specifically, vagrant
up for cdk2b3 not from the openshift-vagrant repo but the
standard distribution).It seems to me that Runtime.exec(etc), Debug.exec(etc), the
external tools launch configuration, and all other solutions are
incapable of being treated as a tty. Only the
org.eclipse.tm.terminal stuff is capable of implementing the
additional requirements to be treated as a tty... however, I
feel that using o.e.tm.terminal on a more regular basis is
misguided. For the first part, it becomes difficult to read its
output. The user can suddenly get involved in the process by
typing things in at inopportune moments. It is impossible to use
without the UI, so can't be done in the background, as well as a
number of other issues that come as consequences of those.In short, it seems applications requiring a TTY environment are
really not that many, and the fact that vagrant-registration
requires it at all is very strange. It most likely needs the TTY
functionality to accept a password without showing it, but I
can't seem to figure out if thats just a guess or not.Either way, I'm going to stick with our current way of doing
things, either via Runtime.exec when we want it in the
background, ro external-tools launch config when we want the
command's output to be shown in a console.
- Rob
On 12/08/2015 08:02 AM, Gorkem Ercan wrote:
For Node.js based tools we needed a fully configured PATH
because it is often the case those tools will make calls to
other apps.
Basically our strategy is to start a full bash/cmd shell (notice
-l for bash) which will be configured fully. [1]
then execute the commands [2]
finally issue an exit to leave the shell [3]The only downside is you can not easily capture the process exit
code.The code examples are from the initial implementation that I
have done for CordovaCLI and uses eclipse libraries for starting
the process however it can be implemented equally same using the
Runtime.exec too. [4][1]
https://github.com/gorkem/thym/blob/use_cli/plugins/org.eclipse.thym.core/src/org/eclipse/thym/core/internal/cordova/CordovaCLI.java#L175
[2]
https://github.com/gorkem/thym/blob/use_cli/plugins/org.eclipse.thym.core/src/org/eclipse/thym/core/internal/cordova/CordovaCLI.java#L135
[3]
https://github.com/gorkem/thym/blob/use_cli/plugins/org.eclipse.thym.core/src/org/eclipse/thym/core/internal/cordova/CordovaCLI.java#L139
[4]https://github.com/gorkem/js-parser-benchmarks/blob/master/src/main/java/org/jboss/tools/benchmark/parsers/esprima/EsprimaParser.java#L70
Gorkem
On Tue, Dec 8, 2015 at 2:09 AM, Max Rydahl Andersen
<manderse@redhat.com <mailto:manderse@redhat.com>> wrote:Question relevant on the list. /max http://about.me/maxandersen On 08 Dec 2015, at 05:09, Rob Stryker <rob.stryker@jboss.com <mailto:rob.stryker@jboss.com>> wrote:Hey Guys: Can you clarify how you guys call filesystem commands like npm and cordova? In the CDK tools as currently coded, we do two different things. One, is that we create an "External Tools Launch Configuration" which runs the command. This requires knowing the actual location of the executable. The other is to simply call Runtime.exec(etc) and get a Process from it. The external tools launch config is useful because it opens a console for us and means we don't have to do any of the wiring, so we use that when we know we want the commands to be visible to the user. We use the runtime.exec() in the background for commands that we want to run without showing the user (for example if we did a vagrant adbinfo) How do you all do it? - Rob Stryker On 12/03/2015 11:36 AM, Max Rydahl Andersen wrote:In plugins/org.jboss.tools.openshift.cdk.server/src/org/jboss/tools/openshift/cdk/server/core/internal/CDKConstantUtility.java <https://github.com/jbosstools/jbosstools-openshift/pull/831#discussion_r46575476>: > public static String getVagrantLocation() { > - return VAGRANT_LOCATION_LINUX; > + return findVagrantLocation(); im wondering if we are better of launching this similar to what @gercan <https://github.com/gercan> and @ibuziuk <https://github.com/ibuziuk> been doing for npm and cordova cli tools. i.e. call out via bash or cmd.exe making it up to the user to have it properly configured in PATH — Reply to this email directly or view it on GitHub <https://github.com/jbosstools/jbosstools-openshift/pull/831/files#r46575476>.