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
        quit application id "com.Growl.GrowlHelperApp"
    end 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).


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;

  • 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 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
  • 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.

  • Will the osa pass its inherited environment on to scripts it spawns with do shell script? – Daniel 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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .