If I type “which jazzy” in the terminal it returns “/usr/local/bin/jazzy” which is correct
but
dim sh as new shell
sh.Execute "which jazzy"
msgbox sh.Resultresults in “” and returns an errorcode of 1
obviously I’m doing “something” wrong here
fyi… this is for macOS only (currently High Sierra)
The TERMINAL is NOT the same thing as a SHELL object - you CAN’T expect the results from TERMINAL to be the same as what you get out of a SHELL object.
Edit: there wasn’t really a question. Are you trying to get which to work in a Shell object, or are you trying to use jazzy in a Shell object?
thanks for that helpful and insight response
My guess is that Dave wants to execute “which jazzy” from Xojo and get Error code 0 and the result being “/usr/local/bin/jazzy”
exactly… I need to know if a user has Jazzy installed or not…
FYI… my above example works fine if I use any other macOS command, or if I specify the path to where Jazzy is (which of course defeats the purpose)
If you want to check the user-defined paths through which, this post might help:
https://forum.xojo.com/conversation/post/396129
It logs in as the user exactly as they would through Terminal and reports the results of which.
Ironically, you may need to enter the full path of which.
rather defeats the purpose 
But after further research I found that Jazzy should by default be installed in /usr/local/bin
so for my purposes I will check there, and if not leave it up to the user to move things
or perhaps I’ll provide an option to change the “default” search location
Ok, ok, now I understand (I think).
Shell.execute, doesn’t include /usr/local/bin, so ‘which’ will report “” and error code 1 on any binary on that directory.
From what I can tell, it works with files in /bin and /usr/bin at least.
Ok, my last post in this topic.
I was able to make which work with /usr/local/bin too, I just added this before Dave’s code:
System.EnvironmentVariable("PATH")="/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin"so Dave, if you can try the following code:
System.EnvironmentVariable("PATH")="/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin"
Dim sh As New shell
sh.Execute "which jazzy"
msgbox sh.Result
Edit: I created a ‘jazzy’ file in /usr/local/bin and it works.
Thanks
[quote=397665:@Axel Schneider]better use command -v
see https://forum.xojo.com/conversation/post/278819[/quote]
This doesn’t work:
Dim sh As New shell
sh.Execute "command -v jazzy"
msgbox sh.Result
This works:
System.EnvironmentVariable("PATH")="/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin"
Dim sh As New shell
sh.Execute "command -v jazzy"
msgbox sh.Result
Ah, you mean use ‘command -v’ and not ‘which’ because some systems may not have ‘which’, right?
Hi Dave (and anyone who stumbles onto this in the future):
The ELI5 explanation of what’s going on is this: When you open a terminal, it fires up a session in your $SHELL of choice. On OS X, this is usually /bin/bash, and bash comes with a set of pre-defined paths already set up by default, including /usr/local/bin/
A shell object in Xojo does not fire up a bash session, so you don’t get all the same paths loaded that you do in terminal. Since the which command searches the current path to see where the requested executable lives, you need to have the same paths set up to get the same result. This is why it is not working in the Xojo shell - it’s not running a bash shell under the hood.
However, you can run a command through bash in a Xojo shell, and get the same paths loaded that way. What happens when you try this?
Dim sh As New shell
sh.Execute "/bin/bash -lc ""which jazzy"""
MsgBox sh.Result
As I suggested that as a solution through a link several posts ago, I have to believe that doesn’t meet his needs.
Odd. It returns EXACTLY what he was asking for.
yes, yes you did, and for some reason I managed to overlook your response,… but that does work perfectly
and Kimball… thanks
In your face, Kimball!
Er, I mean, great, glad that worked out for you.
Including /usr/local/bin into EnvironmentVariable doesn’t work with High Sierra? I’m using Sierra.
Of course, not needing to change a system variable is a better way to do things, just curious.
For that reason alone, I didn’t go that direction… but it was a good idea.