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.
