On 12/13/2012 07:45 PM, Steven D'Aprano wrote: > When I call "python some_script.py" from the command line, it runs under > Python 2.7 as I expected. So I give the script a hash-bang line: > > #!/usr/bin/env python > > and run the script directly, but instead of getting Python 2.7, it runs > under Python 2.4 and gives me system errors. > > When I run env directly, it ignores my alias: > > steve@ando ~]$ /usr/bin/env python -V > Python 2.4.3 > > > What am I doing wrong?
Hash-bang isn't a shell function; it's a kernel function. There's no reason why a shell setting (alias) would be known to the kernel. Different shells have different ideas about aliases anyway. And the program that the she-bang tells the kernel to run is /usr/bin/env, again something that doesn't have anything to do with the shell. The only thing the shell can communicate to the env program is the environment, including the PATH variable, which env searches. The reason it works this way is that the shell is simply another program that can be replaced. One could make a shell based on python, and it might replace the bash "alias" command with a completely different mechanism. When I was first exposed to Linux, it took me a long time to understand and appreciate how basic commands like ls and env are not part of shell at all, unlike my experience with the DOS and Windows command.com and cmd.exe shells. At first I found this archaic and frustrating. But later I realized the great power of doing things this way. If I didn't like the way ls listed things, I could change it; replace ls easily. I remember seeing TSRs (remember them!) that would hook into command.com and patch it to add or alter command.com commands. The Unix way was definitely cleaner. -- http://mail.python.org/mailman/listinfo/python-list
