I'm gett a strange problem when running python script from linux, it doesn't seem to bother running the script file (I've put a print statement on the first line and it doesn't come out):
zl#o-xterm-71 h2bin> python main.py
Python 2.7.3 (default, Feb 4 2013, 18:00:47)
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>
The script runs fine on my laptop with 2.7.5, and even with 2.4.3 so I'd assume it's not a version problem. Should be something simple that I missed.. Anyone had this before? Thanks!
edit1：
dummy.py:
def main():
print "it works"
if __name__ == '__main__':
main()
output:
zl#o-xterm-71 h2bin> python dummy.py
Python 2.7.3 (default, Feb 4 2013, 18:00:47)
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>
Typing 'python' gives the exact same thing.
tarvalon:/tmp$ cat dummy.py
def main():
print("it works")
if __name__ == '__main__':
main()
tarvalon:/tmp$ python dummy.py
it works
So, it works. There's some problem with your installation. Looks like your python file is a script that is calling the real python binary without parameters. Best commands to debug that: file which python, cat which python and, most important, python --help.
Not 100% sure about this, but I think the quotes are messing things up for you.
Change:
print “it works”
To
print "it works"
You could explain this behaviour if someone/something put a wrapper script/program named python in your PATH, that runs a real Python interpreter, but neglects to pass the arguments.
Related
On my Linux machine, directly execute python command, it shows that my Python is UCS4 build.
Python 2.7.3 (default, Jan 8 2018, 17:43:28)
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> if sys.maxunicode > 65535:
... print 'UCS4 build'
... else:
... print 'UCS2 build'
...
UCS4 build
However, when I call python in C++ program using
Py_Initialize();
PyRun_SimpleString("import sys");
PyRun_SimpleString("if sys.maxunicode > 65535:\n print 'UCS4 build'\nelse:\n print 'UCS2 build'");
it prints "UCS2 build".
Other information from the python called by c++ are:
platform:Linux-2.6.32_1-19-0-0-x86_64-with-centos-6.3-Final
('Python', '2.7.5 (default, Apr 13 2016, 14:25:24)
[GCC 4.4.6 20120305 (Red Hat 4.4.6-4)]')
('Python', '******/venv')
I have double checked the python executable path. They are from the same path, but python version and gcc version are different.
Anyone know the reason of this strange sympotom?
Well, I solved this problem. Using ldd command, I found that libpython2.7.so.1.0 pointed to a wrong default path, not the one printed before. Correct the LD_LIBRARY_PATH solved this confusion.....
When I run the python3 command, nothing happens. No stdout, no stderr... nothing. When I try the python2 command, however- I get the expected result. What is going on?
ubuntu#ip-172-91-23-255:~$ python3
ubuntu#ip-172-91-23-255:~$
ubuntu#ip-172-91-23-255:~$ which python3
usr/bin/python3
ubuntu#ip-172-91-23-255:~$ python2
Python 2.7.12 (default, Nov 19 2016, 06:48:10)
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>
Just solved the same issue
If you renamed the python executable change it back, else, ignore this.
add the folder of python3 instalation to the PATH,
the instalation folder is possibly
this: C:\Users\RV420\AppData\Local\Programs\Python\Python37-32
To add folders to your path you can just search 'environment
variables' on windows, then click on environment variables and find
one called path
Now make sure that the new folder comes first in the path that the Python2 instalation folder
You're good to go
I wrote a module that behaves differently when executed from command line or is imported as a module, e.g.:
if __name__ == "__main__":
print("Aloha Main")
else:
print("Aloha Module")
Though, when i import this module in python3 interactive session, I don't get the prompt return, I have to press an extra "Enter" to get the prompt back. The same when calling the the functions in this module. The problem disappears when I comment out the "print" statement after "else:". Is it possible to get the prompt back even wiht "print" in place?
UPDATE: Here is a test.py that demonstrates this behaviour
if __name__ == "__main__":
print("Aloha Main")
else:
print("Aloha Module")
and I get:
% python3
Python 3.6.0 (default, Dec 23 2016, 12:51:31)
[GCC 4.2.1 Compatible Apple LLVM 7.3.0 (clang-703.0.31)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import test
>>> Aloha Module
>>>
I had to press enter to get back to the prompt after "Aloha Module". This is running Python 3.6 on OSX. No problems on Python 2.7 on the same system.
UPDATE 2: This is specifically an issue in OSX 10.11.6, I tested this on my Linux box and I did get the prompt back under python 3.6. I use the OSX built-in terminal.
When I type "python" and return in shell, the following lines will come out:
Python 2.7.1+ (r271:86832, Apr 11 2011, 18:05:24)
[GCC 4.5.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
How to surpress these lines please?
An easy way is to call Python as python -i -c "". This will also disable any start-up scripts, though. If you have a start-up script, you can also use python -i ~/.pythonrc.py (or however that script is named).
I have a script that calls os.execvp into another Python instance. After doing this, I appear to be attached to a cmd.exe instance, not the Python instance I just created. The Python instance responds to Ctrl+C however.
H:\bin>Python 3.2.1 (default, Jul 10 2011, 21:51:15) [MSC v.1500
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> print('hi')
Can't find file ('hi')
H:\bin>
H:\bin>
KeyboardInterrupt
>>> echo hi
hi
The call to exec:
from sys import argv
os.execvp('python', argv)
How do I replace the original Python instance with the new one, as per the behaviour one might see on Linux?
On Unix executing binaries is split into two stages - fork(3) to clone current process and exec(3) to load executable into address space. On windows there is only CreateProcess which does the same thing as fork+exec.
For portability your best bet is to use subprocess.Popen (which also does proper filename quoting on Windows unlike os.* counterparts) as in http://docs.python.org/library/subprocess.html#replacing-the-os-spawn-family