How to handle errors?

[Wildman]

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!