Emscripten returns with error code 0 if python2 is not found.

[juj]

After the recent mods that require manually setting up a link to python2, if the user has not set up a link, running emscripten tests finish with an exit code 0 (success).

Expected that in such case a failure error code is returned.

See the recent buildbot results on OSX http://clb.demon.fi:8112/waterfall , where the build reports success, even though the output was this http://clb.demon.fi:8112/builders/osx-emcc-master-tests/builds/17/steps/OSX%20test%20emscripten%20master/logs/stdio

(Btw, would it be possible to look at this again if it is possible to automate the 'python' vs 'python2' somehow so that user does not need to do this manually?)

[kripken]

How is the test runner invoked on the buildbots? If done by python tests/runner.py .. then tests pass ok for me (we do not rely on the shebang with python2). If it is ./tests/runner.py .. then it fails immediately on not finding python2. I would guess the latter from the very short output, except that it says "will skip" which implies that it was called properly.

[kripken]

(Btw, would it be possible to look at this again if it is possible to automate the 'python' vs 'python2' somehow so that user does not need to do this manually?)

I am still thinking about this, and @alanklingman said he would too. But I am not sure there is a better solution - the default must be python or python2, and it will not work on some systems. The only alternatives to having one of those two appear to be

1. `#/usr/bin/env python || python2
2. Run an install script that rewrites the shebangs to what is detected as working

The former looks simple, but will lead to a lot of annoying warnings on half the systems (ones where python is not defined), and the latter adds a lot of complexity (right now, there is no install step at all).

We could add compatibility scripts though, like emcc2 that all it does is use the other shebang, and run emcc, would that help? People would need to know to run it though.

[modeswitch]

What about splitting the shell script part from the python part? So instead of having just emcc, we have instead emcc.py, which is the python part of the current emcc (without the interpreter line), and then the new emcc has shell script logic to figure out which python to call. We would need to do this for each script that might need to be invoked from the shell. It seems like that's only the scripts in shared.py@263:276 and runner.py?

I can make a pull request so that this is more clear if you like. Scratch that, it just moves the complexity onto Windows instead.

[modeswitch]

@juj Is it reasonable to invoke emcc or the test runner by passing it to your interpreter instead of relying on the shebang line when the python2 symlink is not present?

[kripken]

But how does the new file get run? You would need to run it with python .. I assume - isn't that just kicking the problem further down the road? Maybe I'm missing something.

[modeswitch]

@kripken I was thinking about using separate shell scripts (where we can have more logic than is possible in a shebang) to launch the python scripts, but that won't work well on Windows.

@juj, the problem you mentioned where the return code is 0 when the tests fail should be fixed. I will look into it.

[modeswitch]

@kripken Something like this may work better than #!/usr/bin/env python2:

#! /bin/sh

""":"
PYTHON2_PATH=`/usr/bin/env which python2 2>/dev/null`
HAS_PYTHON2=$?
PYTHON_PATH=`/usr/bin/env which python 2>/dev/null`
HAS_PYTHON=$?

if [[ $HAS_PYTHON2 -ne 0 ]]; then
  if [[ $HAS_PYTHON -eq 0 ]]; then
    PYTHON=${PYTHON_PATH}
  else
    echo "error: could not find a python interpreter"
    exit 1
  fi
else
  PYTHON=${PYTHON2_PATH}
fi

exec $PYTHON "$0" "$@"
" """

__doc__ = """<insert doc string>"""
print "Hello world!"

The code above should run in both the shell and in python, and should fall back to python if python2 isn't found. The downside is that it's not as compact.

[kripken]

It might be best to do #!/usr/bin/env python2 || python as suggested earlier, it is at least simple, I am worried about any complexity. Any downsides to that? It would work if python2 is present, and work with a warning if python is present but not python2. At least on Linux, would be great if someone can test it on OS X.

[modeswitch]

Does that actually work? I tried running this

#!/usr/bin/env python2 || python

print( "Hello world!" )

and I got

/usr/bin/env: python2 || python: No such file or directory

[kripken]

Hmm I am sure I saw this working before. And

$ env python321 || python2
env: python321: No such file or directory
Python 2.7.3 (default, Sep 26 2012, 21:51:14) 
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 

works. But in the shebang it does not...

[modeswitch]

The other alternative here is to back out the changes I made and I can write up instructions on using virtualenv to set up emscripten. That means zero changes for the emscripten source and a little extra setup one some platforms that I'm happy to add to the emscripten docs.

Sadly, the situation with python these days seems to make it necessary to inconvenience at least some users. :/

[kripken]

Yeah, there is no perfect solution here. Might as well leave it as is. It slightly annoys me that on some of my machines I need to add a python2 symlink, but it isn't that bad.

[juj]

I now got to configuring the OSX buildbot to have the python2 symlink as well.

In /usr/bin, I issued

sudo ln python python2

to create the python2 executable. But after that, trying to invoke python2 gives the error

python2: posix_spawn: /usr/bin/python22.7: No such file or directory

python2.7 does however exist, so from that I also monkeyed in /usr/bin

sudo ln ../../System/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7 python22.7

after which calling python2 does work. Is that the thing that I should have done? That felt somehow hackish. We don't currently have a good "Getting started with OSX" page that would have these listed up-to-date :/

[kripken]

Can you see where the python22.7 is coming from? Something is appending 2.7, I am curious what.

[juj]

I do not know how to check that. I'm setting up a new OSX box, and I'm seeing the exact same issue, but I'm not sure how to fix this properly. The workaround I mention above still works. Any ideas?

[kripken]

Hmm, only idea is to run the command that generates the python22.7 error, and look at every step of what is called to see where it comes from with debug printouts...

[VikasIndia]

I got the same problem a few months before. I realized it was the drive fomrat (volume format) which caused issue while transferring large files. I had to set the volume format to "Mac OS Extended" instead of my earlier FAT32. It worked for me. More details here: http://www.optimum-systems.com/2013/07/mac-error-code-0.html

[stevenvachon]

$ emcc imagemagick/utilities/identify.c
env: python2: No such file or directory

I know that I have python installed because I use node-gyp.

[JacopoDaeli]

@stevenvachon I have just fixed with this on OSX 10.9:
$ cd /usr/bin
$ sudo ln python2.7 python2

[edwardmp]

Similar issue, had to do this to fix:
sudo ln -s /usr/bin/python2.7 /usr/bin/python22.7

[wyudong]

For people who encountered the error: python2 command not found when installing Emscripten in OS X 10.11 El Capitan, you need to make some changes based on this Platform-specific notes for
Mac OS X.

Before type the following commands in the terminal, refer to this post to disable System Integrity Protection first. Then use the new commands which at least solved my python2 command not found problem.

cd /usr/bin
sudo ln -sf python python2
sudo ln -sf ../../System/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7 python22.7

[juj]

Fixes in incoming, so closing.