How to handle errors?
Wildman
best_lay at yahoo.com
Fri Oct 21 13:06:48 EDT 2016
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 at 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 at 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!
More information about the Python-list
mailing list