Re: Works in Terminal, not as "do shell script"
Re: Works in Terminal, not as "do shell script"
- Subject: Re: Works in Terminal, not as "do shell script"
- From: "Mark J. Reed" <email@hidden>
- Date: Sun, 4 Apr 2010 14:29:23 -0400
Always using full paths is good for security hut bad for portability -
a tradeoff, as so many things are. If you want to find exif whether
installed manually (so probably in /usr/local/bin), via MacPorts
(/opt/local/bin), Fink (/sw/bin), etc, you can explicitly ask for the
user's full environment:
do shell script "bash --login -c " & quoted form of "what you would
normally send to do shell script directly"
but that may have odd effects if their shell startup files try to do
somethzing interactive.
On Sunday, April 4, 2010, Axel Luttgens <email@hidden> wrote:
> Le 4 avr. 2010 à 16:34:59, Rob Lewis a écrit :
>
>> Could someone please explain why this works fine in Terminal:
>>
>> /usr/bin/which exiftool
>>
>> returning the correct path: /opt/local/bin/exiftool
>>
>> while in AppleScript, this:
>>
>> do shell script "/usr/bin/which exiftool"
>>
>> returns: error "The command exited with a non-zero status." number 1
>>
>> Other shell commands like "ls" work OK.
>> And this works too:
>>
>> do shell script "which which"
>>
>> returning: "/usr/bin/which"
>>
>> The exiftool command is installed and works when invoked with /opt/local/bin/exiftool
>
> Hello Rob,
>
> According to the man page of which(1), that command is used to "locate a program file in the user's path".
>
> As Doug already mentioned the fact, this thus relies on the value of the PATH environment variable. It is thus interesting to compare the output of:
>
> echo $PATH
>
> when run in terminal to the one produced by:
>
> do shell script "echo $PATH"
>
> when run in AppleScript Editor for example. It is very likely that the latter outputs "/usr/bin:/bin:/usr/sbin:/sbin", while the former should be similar to "/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11/bin:/opt/local/bin" (because you probably installed exiftool via MacPorts).
>
> It is usual for system-provided environments, such as the one provided by "do shell script", to be rather tightly controlled, so as to not depend on arbitrary and possibly uncontrolled user settings; this is just elementary security.
>
> In that same vein, you may be interested in comparing the outputs of
>
> set vs do shell script "set"
> export vs do shell script "export"
>
> The moral is: always use full paths when referring to executables. If an executable has been installed with the system, you unambiguously know where it has been installed; if you expect an executable to be installed in /opt/local/bin, it should be there: any other place would be suspect.
>
>
> HTH,
> Axel
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> AppleScript-Users mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
> Archives: http://lists.apple.com/archives/applescript-users
>
> This email sent to email@hidden
>
--
Mark J. Reed <email@hidden>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden