[Pythonmac-SIG] Running Python scripts without full paths

Neil Mayhew niel_mayhew@mac.com
Sun, 01 Dec 2002 23:25:35 -0700


I'm a bit late with this contribution, but I hope a few points may still be
helpful.

1. Changes to environment variables like PATH only last for the lifetime of
the current shell (and its descendents). So commands like "setenv PATH ..."
won't have any permanent effect.

2. ~/.MacOS/environment.plist is intended primarily for apps running in the
GUI. I assume it is read by WindowServer and/or loginwindow.app, and these
are the parent processes of all the other GUI processes (as shown by the
PPID column in ps -xl).

3. Although Terminal is a GUI app, the shell running inside it is not. And
Terminal's environment is not the same as the shell's environment.

4. If you have the Terminal preference "Execute the default login shell
using /usr/bin/login" set, your shell starts with a completely fresh
environment (this is how login is supposed to behave) and environment.plist
does not apply.

5. What happens to your environment from there on depends entirely on the
initialization sequence used by your chosen shell. I use bash, because it is
the standard, because it's also the default shell on the linux boxes I use,
and because I don't like tcsh :-). The man pages for bash (and also, I
presume, for tcsh) specify quite clearly what the initialization sequence is
supposed to be. This is not an Apple thing, but a shell thing. In the past,
some of the manpages supplied with OS X were out of sync with the programs
they documented, but Apple has supposedly fixed all of this.

6. If you don't have the "login" Terminal preference set, you are much less
likely to get a consistent environment in your shell, especially across OS
upgrades. With login, you get to control everything precisely.

7. If you want to change your preferred shell (hint, hint :-) the correct
way to do this is using Netinfo Manager. That way you get the same shell
however you log in (including remote login via SSH, useful for escaping from
'stuck' situations without hitting the reset switch).

8. The logical place to set up extra path directories and suchlike is in
your shell's login initialization files. There's usually no need to do this
for GUI programs since they aren't using PATH to find things. There are
exceptions, such as AppleScripts that use "do shell script", but these will
always be fragile if they rely on certain directories being externally set
in the PATH. It's better to use ~ expansion, absolute paths, or
AppleScript's "path to me" to concoct absolute paths. If you use AppleScript
Studio to develop your scripts, then you can put the python, shell, etc.
scripts into the app's bundle (in the Resource directory) and use bundle
APIs to locate them.

9. It's a known problem with cron that environment, path, limits, etc. are
rather unpredictable, especially between different systems, or different
configurations. It's better to have cron run a shell script which then
creates a suitable environment for whatever program you actually want to
run.

10. As has already been pointed out, your commands to add directories to the
path should always ADD to what's already there, not replace it.

11. Most systems by default do not include the current directory in the
path. Thus it is necessary to type ./foo instead of just foo. This is for
security, to stop people spoofing you by putting a script called "ls" into
your home directory that prints nothing (think about it). This was a
favorite trick to play on friends when I first started using Unix, way back.
Of course, more sinister tricks can be played by those with malicious
intent. The trailing (or leading) : in the path is to include the current
directory (ie an empty prefix on whatever command you typed).

I hope this is helpful. And apologies to everyone else for starting up this
extensive off-topic discussion again.

--Neil
 
niel_mayhew@mac.com
(address deliberately misspelled to foil spammers)