Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I am attempting to install an application, but the installer fails with the following error message:

sh: sed: command not found

and there is an Edit and OK button in the dialog, so I click the Edit button which launches the AppleScript Editor to show me the script that is executing. Running it from within the Editor doesn't work either.

The first line of the script with sed is

set currdir_modified to do shell script ("echo " & currdir & " | sed 's/ /\\ /g'")

I went to the terminal to make sure sed was available, and it is, in /usr/bin.

This sounds like a path problem, but I am not sure where to go from here. What can I do to further troubleshoot or solution this issue?

I have successfully installed this app on another mac running the same OS X version, so it is specific to my mac and the application's support is not providing any more help because it is my mac's problem, not theirs.

share|improve this question
    
Do you have MacPorts or Fink installed or something else that's changing your PATH? echo is (usually) in /bin and sed is (usually) in in /usr/bin –  Steve Folly Apr 28 '10 at 7:00

2 Answers 2

up vote 1 down vote accepted

It seems like you have modified the default PATH that is inherited by GUI applications (including most AppleScript runners). If you just want a quick fix, you should be able to do what Hasaan Chop indicates: just change sed to /usr/bin/sed in the AppleScript code, save it, and re-run the installer (though you may run into similar problems with other commands).

If you want to fix the problem that caused /usr/bin to be missing from the default PATH, then you will need to poke around a bit to find out where the problem started.

Note that (as you indirectly found out) the “default PATH” that an application sees is different from the PATH that a “login” shell started by Terminal will set up for itself. Shells in the Bourne family (bash, zsh, ksh, etc.) in “login” mode will run /etc/profile which (usually) completely resets PATH to a new value (also per-user shell initialization files will usually add various other directories to the PATH). The main point here is that shell initialization files have nothing to do with the PATH that applications see (there are exceptions (e.g. Aquamacs) but they are rare).

  • A common place for customized, default environment variables is ~/.MacOSX/environment.plist.

    This file is read at login time and is used to add new (or override existing) environment variables for applications started in the current login session.

    To view and/or edit this file, you can use a specialized tool like RCEnvironment (recommended).
    Or since this file is a plist file, you can use Property List Editor (from the Development Tools), or command line tools like defaults, or PlistBuddy. If the file is in XML format (likely), then you could even use a plain text editor.

  • Another possible location for customized, default environment variables is the set of launchd configuration files.

    These files can contain any launchctl subcommands, including the setenv and unsetenv subcommands that can change the environment that child processes inherit.

    Per-user customization can be done in ~/.launchd.conf. System-wide customization is done in /etc/launchd.conf.

If you find that one of these files is manipulating the PATH environment variable, you should either get rid of the PATH manipulation (to let the default value pass through to applications) or add the low-level default directories (e.g. /usr/bin:/bin:/usr/sbin:/sbin) to whatever custom directories you need to have in PATH.

If you end up making changes to a per-user file (~/.MacOSX/environment.plist or ~/.launchd.conf), then the easiest way to make the changes effective is to logout (full logout, not just a fast user switch) and login. If you had to modify a system-wide file, then the easiest thing to do is to reboot. Technically it is possible to start using the new values without rebooting or logging out, this is left as an ‘exercise for the reader’.


The following is an aside regarding the implications of that single line of AppleScript code, it is not germane to the PATH problem.

That line of code has another potential error, too (failure to properly quote the string value of currdir into the shell code). The line itself is supposed to add backslashes before every space character in a string. The most likely reason to do this is so that the resulting string can be directly inserted into another bit shell code. The problem is that there are many other characters that need to be escaped in the same way if the shell code is going to work properly given any string. Both of these problems (really they are the same problem) can be easily solved by using the AppleScript's quoted form of command. The fact that the script is not using quoted form of is a sign of inexperience which makes me a nervous about what else the script might be doing incorrectly.

share|improve this answer
    
I had forgotten that I had created a .MacOSX/environment.plist file based on some advice when I installed macports. In my version, I had all the usual paths except /usr/bin. I just added that to the path, logged out, logged in and my install worked. –  jsmorris Apr 29 '10 at 4:43

Use an absolute path to the sed binary rather than just the command name.

share|improve this answer
    
Right instead of just sed, use /usr/bin/sed –  Doug Harris Apr 28 '10 at 4:19
    
This a good tip, however it doesn't explain why it works on another machine running the same OS X version. –  Steve Folly Apr 28 '10 at 6:57
    
It will probably work on your machine as well if you log in as a different user. The only person who can explain what you did to your shell environment is you. –  Hasaan Chop Apr 29 '10 at 22:53

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.