[Pythonmac-SIG] Running Python scripts without full paths

[Daniel Lord]

And, worse yet, when Apple implemented their repelace, they didn't 
think about variable expansion so user customizations like "~" and 
environment variables that owrk on all other systems like ${CLASSPATH} 
and ${PYTHONPATH} are inert in a plist further messing things up. 
Perhaps an application of the Law of Unintended Consequences. But is 
sure makes life on OS X difficult.

On Saturday, Nov 30, 2002, at 15:06 US/Pacific, Jack Jansen wrote:

>
> 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 -
>
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
>