[jbosstools-dev] [jbosstools-openshift] JBIDE-21175 - ensure more reliable locating of vagrant command (#831)

[Gorkem Ercan]

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> 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>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>
>> 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/7e32765e/attachment.html