I'm working on a new server for a new workplace, and I'm trying to reuse a CGI script I wrote in Python earlier this year. My CGI script starts off with
#!/local/usr/bin/python
But when I run this on the new server, it complains that there's no such folder. Obviously Python's kept in a different place on this box, but I've got no idea where.
I haven't done much unix before, just enough to get around, so if there's some neat trick I should know here I'd appreciate it :)
Thanks!
Try:
which python
in a terminal.
For this very reason it is recommend that you change your shebang line to be more path agnostic:
#!/usr/bin/env python
See this mailing list message for more information:
Consider the possiblities that in a different machine, python may be installed at /usr/bin/python or /bin/python in those cases, #!/usr/local/bin/python will fail.
For those cases, we get to call the env executable with argument which will determine the arguments path by searching in the $PATH and use it correctly.
(env is almost always located in /usr/bin/ so one need not worry that env is not present at /usr/bin.)
# which python
/usr/local/bin/python
Update:
I misread. Replace your header with
#!/usr/bin/env python
This will pull in the python location from the user that runs the script's environmental settings
Try: which python or whereis python
It is a good idea to use backticks for header Python script:
`which python`
The proper way to solve this problem is with
#!/usr/bin/env python
which allows for the use of a binary in the PATH in a shebang.
Related
I have a hello.py file located in "/home/user1/public_html/cgi-bin" that displays the python version:
#!/usr/bin/python
import platform
print "Content-type: text/html\n\n"
print(platform.python_version())
When I go to the url for the script, it displays "2.6.6" in the browser.
I am wanting to use python 3.5 so I had the webhost install a virtualenv in "/home/user1/virtualenv/testproject/"
When I try to change the first line of the code to:
#!/home/user1/virtualenv/testproject/3.5/bin/python
import platform
print "Content-type: text/html\n\n"
print(platform.python_version())
the script will display "It works! Python 3.5.5" which is not what I have coded into the script.
Am I supposed to put the hello.py file into the virtualenv directory? Or is it that I have the path to the python 3.5 incorrect? Or am I just totally misunderstanding how all of this works? Any help would be appreciated.
This will definitely resolve your problem
Your Code is correct nothing to worry because it will gives correct output in interpreter.
This problem is happening because you installed two versions of python on your machine and by default the path of python 2 is set in the priority in your Environment Variable.
The Script gives correct output in interpreter because priority of path is not required for interpreter but when you run it from browser or command-prompt or console then path is required and it search the path of python from system environment variable.In your case, First it got the path of python 2 ,so that its show the version of python 2
Their will be two solution for your problem, You can do anyone.
Uninstall python 2 from your system. This will resolve your problem instantly.
If you want to keep both version of python then for resolving this problem you should have to set the path of python 3 in the priority from environment variable. Like This
See in the Screenshot, Path of Python 2 is Upper in the Environment Variable should be below the Path of Python 3
Like This
This is the correct and static way to set the path in priority
Thank you, Expecting This will resolve your problem
phd's comment was the correct answer. print is a function in Python 3, so you must call it: print("Content-type: text/html\n\n"). print-as-operator is a SyntaxError in Python 3.
I have downloaded a python program from git.
This program is python 3.
On my laptop i have both python 2.7 and python 3.4. Python 2.7 is default version.
when i want run this program in terminal it gives some module errors because of it used the wrong version.
how can i force an name.py file to open in an (non) default version of python.
I have tried so search on google but this without any result because of lack of search tags.
also just trying things like ./name.py python3 but with same result(error)
When you type "python", your path is searched to run this version. But, if you specify the absolute path of the other python, you run it the way you want it.
Here, in my laptop, I have /home/user/python3_4 and /home/user/python2_7. If I type python, the 3.4 version is executed, because this directory is set in my path variable. When I want to test some scripts from the 2.7 version, I type in the command line: /home/user/python2_7/bin/python script.py. (Both directory were chosen by me. It's not the default for python, of course).
I hope it can help you.
Use the shebang #!<path_to_python_version_you_want>
As in:
#!/usr/bin/env python
at the very top of your .py file
Also checkout: Should I put #! (shebang) in Python scripts, and what form should it take?
The Method of #Tom Dalton and #n1c9 work for me!
python3 name.py
I'm sure this is well documented somewhere, but I can't find it! I want to make my scripts portable to machines that may not have their Python interpreters in the same location. For that reason, I thought that I could just code the first line as #!python3 rather than with the absolute path to the interpreter, like #!/usr/local/bin/python3.
No doubt most of you understand why this doesn't work, but I have no idea. Although my lab mates aren't complaining about having to recode my scripts to reflect the absolute path to the interpreter on their own machines, this seems like it shouldn't be necessary. I'd be perfectly happy with a response providing a link to the appropriate documentation. Thanks in advance.
The path given after #! in the shebang line is an absolute path, so simply python3 does not work. You should use
#!/usr/bin/env python3
to look up python3 in the PATH on a POSIX machine. Of course this will only find the Python interpreter if it is in some directory given in the PATH environment variable.
env is a program that handles these sort of things. You should pretty much always use something like #! /usr/bin/env python3 as your shebang line rather than specifying an absolute path.
I have a problem which is caused by our encapsulated design. Up till now lots of our scripts were written in bash and as a result the #!/bin/bash was always simple.
However now that we are rewriting our scripts in python that is a bit more difficult. We deliver a specific version of python (to avoid version differences in client installed environments from breaking our implementation). Because the specific version of python lives in a installed directory structure I need to route to it.
However I don't think the #! statement can accept environment variables from the shell that executes the file(tried and got a bad interpreter).
eg:
in foo.py I have #!$dirloc/wherepythonlives/python
In the bash shell I executed the file and got bad interpreter.
Is there a way of sneaking an environment variable into that #! line?
Or will I have to depend on an explicit path? We want to support multiple versions of our software (which may mean multiple python versions) on one environment so I was hoping to somehow keep Python's !# statement inside the directory level we install into.
A common way to do this is to use the env program:
#!/usr/bin/env python
This will cause env to look along the PATH environment for a binary called python.
I'm not aware of being able to use environment variable in the shebang. You can use relative paths though
#! ../../usr/bin/python
edit:
You could always use env to specify to use a specific version. Then if that version can be found in $PATH it will be used otherwise the script will fail
#! /usr/bin/env python2.7
Or you could make the entry point a generic script instead.
eg
#! /usr/bin/env bash
if [[ $MYPYTHON ]]
then
$MYPYTHON main.py
else
echo error message
fi
The optimal solution to this dilemma is using distutils (setup.py, which creates correct stubs for you automatically, for a number of given "console entry points") and virtualenv (handling the "isolated multiple installations" part).
I suppose it all depends on how and in what environment your scripts will be invoked. You could call you scripts using #!/usr/bin/env python, which would allow you to control which python is used by manipulating the environment's PATH.
You could always specify a wrapper script as the interpreter, which runs a python executable relative to the script's location:
foo.py:
#!/bin/pyselector
import sys
sys.exit(0)
pyselector:
#!/bin/sh
SCRIPT_PATH="$(readlink -f $1)"
SCRIPT_DIR="$(dirname "$SCRIPT_PATH")"
"${SCRIPT_DIR}/my/local/python" "$#"
The typical header should be
#!/usr/bin/env python
But I found below also works when executing the script like $python ./my_script.py
#!/usr/bin/python
#!python
What's difference between these 2 headers? What could be the problem for 2nd one? Please also discussing the case for python interpreter is in PATH or not. Thanks.
First, any time you run a script using the interpreter explicitly, as in
$ python ./my_script.py
$ ksh ~/bin/redouble.sh
$ lua5.1 /usr/local/bin/osbf3
the #! line is always ignored. The #! line is a Unix feature of executable scripts only, and you can see it documented in full on the man page for execve(2). There you will find that the word following #! must be the pathname of a valid executable. So
#!/usr/bin/env python
executes whatever python is on the users $PATH. This form is resilient to the Python interpreter being moved around, which makes it somewhat more portable, but it also means that the user can override the standard Python interpreter by putting something ahead of it in $PATH. Depending on your goals, this behavior may or may not be OK.
Next,
#!/usr/bin/python
deals with the common case that a Python interpreter is installed in /usr/bin. If it's installed somewhere else, you lose. But this is a good way to ensure you get exactly the version you want or else nothing at all ("fail-stop" behavior), as in
#!/usr/bin/python2.5
Finally,
#!python
works only if there is a python executable in the current directory when the script is run. Not recommended.
I'd suggest 3 things in the beginning of your script:
First, as already being said use environment:
#!/usr/bin/env python
Second, set your encoding:
# -*- coding: utf-8 -*-
Third, set some doc string:
"""This is a awesome
python script!"""
And for sure I would use " " (4 spaces) for ident.
Final header will look like:
#!/usr/bin/env python
# -*- coding: utf-8 -*-
"""This is a awesome
python script!"""
Best wishes and happy coding.
The Python executable might be installed at a location other than /usr/bin, but env is nearly always present in that location so using /usr/bin/envis more portable.
From the manpage for env (GNU coreutils 6.10):
env - run a program in a modified environment
In theory you could use env to reset the environment (removing many of the existing environment variables) or add additional environment variables in the script header. Practically speaking, the two versions you mentioned are identical. (Though others have mentioned a good point: specifying python through env lets you abstractly specify python without knowing its path.)
Yes, there is - python may not be in /usr/bin, but for example in /usr/local/bin (BSD).
When using virtualenv, it may even be something like ~/projects/env/bin/python
The /usr/bin/env python becomes very useful when your scripts depend on environment settings for example using scripts which rely on python virtualenv. Each virtualenv has its own version of python binary which is required for adding packages installed in virtualenv to python path (without touching PYTHONPATH env).
As more and more people have started to used virtualenv for python development prefer to use /usr/bin/env python unless you don't want people to use their custom python binary.
Note: You should also understand that there are potential security issues (in multiuser environments) when you let people run your scripts in their custom environments. You can get some ideas from here.