Take the 2-minute tour ×
Ask Different is a question and answer site for power users of Apple hardware and software. It's 100% free, no registration required.

I have problems with some applications that use AppleScript shell script feature. For example, Growl's uninstall scripts shows an error:

error "/bin/sh: rm: command not found" number 127

The source of the script is

display dialog (localized string "title")
if button returned of result = "OK" then
    try
        quit application id "com.Growl.GrowlHelperApp"
    end try
    try
        quit application id "com.Growl.MenuExtra"
    end try
    do shell script "rm -rf /Library/PreferencePanes/Growl.prefPane ~/Library/PreferencePanes/Growl.prefPane" with administrator privileges
    display dialog (localized string "succeeded") buttons {localized string "OK"} default button 1
end if

I've added echo $PATH > /omg.txt && to the command to see what's the search path for rm. But it has a weird value:

$ cat /omg.txt 
â

What can I do? I don't understand what's going on. When I just run sudo /bin/sh in Terminal, the environment is just fine!

Now, I know that to uninstall Growl I can just run the command it tries to run in the Terminal. But it won't solve this problem, just postpone it until another application fails with the same error (it happened before).

share|improve this question

3 Answers 3

According to Apple's official documentation, it is by design that shell scripts invoked from AppleScript's do shell script action do not inherit the $PATH variable from your login shell's environment.

Accordingly, Apple instructs users to use full paths to commands when invoking shell scripts from AppleScript rather than relying on the $PATH variable in the environment.

In the script in your example, you could replace rm with /bin/rm

According to the aforelinked documentation, this is the intended, documented behavior; a script that expects the environment's $PATH to be set for do shell script commands is a script with a bug.

That said, if you absolutely need to use relative paths and use $PATH to complete them, you could prefix any shell script called by do shell script with the command PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin;

share|improve this answer
    
this won't work for all the others scripts :( –  valya Jan 15 '12 at 19:30
    
Scripts that rely on the $PATH variable to be set are, according to the documentation, buggy. See revised answer. –  Daniel Lawson Jan 15 '12 at 21:31

hotfix = give the location of rm command:

do shell script "/bin/rm -rf /Library/PreferencePanes/Growl.prefPane ~/Library/PreferencePanes/Growl.prefPane" with administrator privileges
share|improve this answer
    
it won't solve the problem once and for all :( –  valya Jan 15 '12 at 19:30

You could actually use Daniel's suggestion of exporting paths, but save it as a script unto itself (call it "dss" for do shell script, or something) and place it in usr/local/bin. That way the next time you need to run an osa script like the Growl uninstall, you can call your script from the command line to set $PATH, run the osa job, and then be finished. Not a permanent solution, but highly workable.

share|improve this answer
    
Will the osa pass its inherited environment on to scripts it spawns with do shell script? –  Daniel Lawson Jan 15 '12 at 22:18
    
I believe so, at least if the script is using subroutines. Subroutines of a parent script will inherit the environment variables for that process. –  soxman Jan 15 '12 at 22:54

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.