[Pythonmac-SIG] Running Python scripts without full paths

[Jack Jansen]

On zaterdag, nov 30, 2002, at 21:00 Europe/Amsterdam, kevin parks wrote:

> Someone who really understands this ought to put something up on the 
> web on this!

The problem is that noone really understands it:-(

As I have my historian's hat on today anyway, let me explain a bit how 
we got in the mess we are now.

Initially there was .profile for /bin/sh (only read when a login shell 
started), .login for csh (only read when a login shell started) and 
.cshrc for csh (only read when the shell was *not* a login shell). To 
simplify matters we'll forget about the bourne shell and its brethren 
(bash, zsh, esh, many more).

The csh and its descendents (like tcsh) added system-wide default 
initialization files (/etc/csh.login and /etc/csh.cshrc). Tcsh 
complicated matters, because whereas it shared .login with csh, it 
would prefer a .tcshrc file over a .cshrc file (but fallback to the 
latter if the former didn't exist). Then came windowing systems like 
X11, which would start up applications before anything resembling a 
"login shell" appeared, and you wanted to be able to set environment 
variables there too. So now there were three initialization files: 
.login (login shells), .cshrc (non-login shells) and something else for 
the windowing system (often .xinitrc, but there's other possibilities 
too:-). At this point some systems tried to rationalize things and 
provided /etc/profile.d, which was read by /etc/csh.login as well as 
the equivalents for all other shells as well as by the window system 
startup. At least: each read the bits it thought it required. And each 
of the files in /etc/profile.d could be overridden in your home 
directory (just as /etc/csh.login could be overridden by .login). But 
then people who wanted a custom .login needed to get bits and pieces 
from /etc/profile.d themselves, because .login replaces /etc/csh.login, 
in doesn't add to it. So by this time it was one big giant mess, and 
the only surefire way to get a working set of initialization files was 
to keep experimenting until you had something that worked, and then 
*never* *ever* touch that again (at least not structurally).

And then Apple appeared on the Unix front and made things even more 
difficult because they didn't want to mimic their 
window-system-initialization on X11, probably because they didn't want 
to depend on /bin/sh or /bin/csh in the login sequence, and they 
invented environment.plist.

And, of course, this is only the part of the story that I understand:-)
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -