On Fri, 21 Oct 2016 16:14:41 +1100, Steve D'Aprano wrote: > On Fri, 21 Oct 2016 11:03 am, Wildman wrote: > >> On Thu, 20 Oct 2016 12:48:28 -0700, SS wrote: >> >>> The following script works fine: >>> >>> #!/bin/python >> >> I meant to include this with my other post but I forgot it. >> >> Using a direct path to the Python interpreter can cause problems >> on some systems because it is not always installed to the same >> directory. > > Then you change the path and fix it.
You are assuming that I, the user, knows what a shebang is and what it is used for and what Python is and where the interpreter is located. If you are targeting developers none of that will be a problem but, if your program is for "average users", you may have a serious problem. Personally I would not want to distribute a program that may require the user to fix the code before it will run. >> On my Debian-based system Python is installed in >> /usr/bin. So your code as written will not run on my system. >> A workaround for this is to use env in the shebang/hashbang. > > That's not a work-around. That's a bug waiting to happen. > > One of the problems with of env is that it will use whatever python > executable appears first in the user's $PATH, regardless of whether it is > the right Python or not -- or even whether it is actually Python, or just > some random executable file called "python". For example, you might have > compiled your own experimental Python executable, and adjusted your PATH > environment variable to find it. Now your env scripts will use your > unstable, experimental Python interpreter instead of the system Python. A developer might have complied experimental versions of Python but the average user will not. Here again it depends on your target. > Another serious problem with using env in the hash-bang line is that you > cannot pass commandline options to the Python executable. Not true. I made a test script with this code: #!/usr/bin/env python import sys print sys.argv Then I ran it: ~$ python test.py argument1 argument2 ['test.py', 'argument1', 'argument2'] > Using env in this way is a hack that happens to mostly work. Its arguably an > abuse of env, and its not as portable as people often think (not all older > Unix systems even have env). If you are targeting older Unixes than yes that could be a problem. >> For Python 2: #!/usr/bin/env python >> For Python 3: #!/usr/bin/env python3 >> >> It will not matter where Python is installed. 'env' will always >> know where it is. > > That's not correct: env only searches the PATH, so if your python is not in > the path, it won't be found. Here's env on my system with the default PATH: > > [steve@ando ~]$ /usr/bin/env python -c "import sys; print(sys.version)" > 2.4.3 (#1, Jan 9 2013, 06:49:54) > [GCC 4.1.2 20080704 (Red Hat 4.1.2-54)] > > > But if I change the search path (or if I move the Python executable > somewhere off the path): > > [steve@ando ~]$ PATH="/tmp" /usr/bin/env python -c "import sys; > print(sys.version)" > /usr/bin/env: python: No such file or directory > > > Even if env finds something called "python", you can't be sure that it is > the right version of Python, or even Python at all. All you know is that it > is something called "python" on the search path. Not likely an average user is going muck around with the path in the way you describe. -- <Wildman> GNU/Linux user #557453 The cow died so I don't need your bull! -- https://mail.python.org/mailman/listinfo/python-list
