[jbosstools-dev] [jbosstools-openshift] JBIDE-21175 - ensure more reliable locating of vagrant command (#831)
Rob Stryker
rob.stryker at jboss.com
Tue Dec 8 15:09:36 EST 2015
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. 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.
We've already noticed that Mac seems to generate a different path based
on if you use the .app shortcut or from a terminal. 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.
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.
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/maxandersen
>
>
> On 08 Dec 2015, at 20:34, Gorkem Ercan <gercan at redhat.com
> <mailto:gercan at 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 at jboss.com
>> <mailto:rob.stryker at 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 at redhat.com <mailto:manderse at redhat.com>> wrote:
>>>
>>> Question relevant on the list.
>>>
>>> /max
>>> http://about.me/maxandersen
>>>
>>>
>>> On 08 Dec 2015, at 05:09, Rob Stryker <rob.stryker at jboss.com
>>> <mailto:rob.stryker at 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>.
>>>>>
>>>>
>>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20151208/e28dd751/attachment.html
More information about the jbosstools-dev
mailing list