Wrong shebang on cgi.py

[purplesyringa]

I'm using PyPy 3.8. When invoking /opt/pypy/lib/pypy3.8/cgi.py I get:

$ /opt/pypy/lib/pypy3.8/cgi.py
bash: /opt/pypy/lib/pypy3.8/cgi.py: /usr/local/bin/python: bad interpreter: No such file or directory

This is because cgi.py says:

#! /usr/local/bin/python

# NOTE: the above "/usr/local/bin/python" is NOT a mistake.  It is
# intentionally NOT "/usr/bin/env python".  On many systems
# (e.g. Solaris), /usr/local/bin is not in $PATH as passed to CGI
# scripts, and /usr/local/bin is the default directory where Python is
# installed, so /usr/bin/env would be unable to find python.  Granted,
# binary installations by Linux vendors often install Python in
# /usr/bin.  So let those vendors patch cgi.py to match their choice
# of installation.

I believe the shebang should be replaced with /usr/bin/env python in this image.

[purplesyringa]

There is also a similar bug in the Python 2 image: many files in /opt/pypy/lib-python/2.7 use #! /usr/bin/env python as the shebang, but python is not aliased to pypy in this case (unlike Python 3, where the alias exists).

[tianon]

Looking around in /opt/pypy, it appears there are a lot of technically incorrect shebangs -- we don't provide a python or python3 alias in any of these images, but many of the shebangs point to those. However, looking at cgi.py as an example, the only reason it has a shebang at all is so you can run the cgi.py tests. The way you're normally intended to use it is via import cgi which does not do anything with the shebang (except treat it as a normal comment and thus ignore it).

Is there a particular reason you're trying to invoke cgi.py in this way?

[purplesyringa]

Is there a particular reason you're trying to invoke cgi.py in this way?

I'm not invoking it per se, I'm using a packaging script that scans shebangs for dependencies. Irregarding that, I treat invalid shebangs the same way as invalid imports in Python or invalid interpreter/library paths in ELFs, that is, they aren't expected to exist in a mature public project.

[tianon]

Given that they don't cause any functional harm as-is, short of a recommendation from pypy to do so (or a good use case for running these as scripts directly in the image), we unfortunately don't plan to add (and then maintain) extra code just to try and detect and correct all incorrect shebangs.

I would suggest something like FROM pypy:xxx + RUN find /opt/pypy -name '*.py' -exec sed -ri -e 'YOUR-REGEX-HERE' '{}' + for users who want to attempt doing so in an automated way.