Jython's runner (sys.executable) is a .sh, or .bat file on Windows. On
POSIX a .sh file cannot be used as a shebang line interpreter, meaning:
#!/path/to/jython
does not work
One partial workaround is to have distutils (and setuptools) change the
interpreter to:
#!/usr/bin/env /path/to/jython
We're getting this workaround applied to both because it's dead simple
and allows most scripts to work, but this solution has its own problem:
it doesn't work when extra arguments to the interpreter are used. I.e.
on various platforms (like Linux IIRC, and some others), this does not
work:
#!/usr/bin/env /path/to/jython -S
There exists a similar issue on Windows for setuptools -- as setuptools
installs scripts with an accompanying .exe file to facilitate easily
running scripts on Windows as you would on POSIX. This helper .exe
doesn't work for the same reason, because our sys.executable is a .bat.
The fullproof solution here is to make the runner a native executable on
all platforms. This wouldn't be too bad to accomplish for Windows as we
could just ship a precompiled .exe.
However shipping pre-compiled executables for the various POSIX
platforms would be a big pain. Having the Jython installer detect a
compiler and compile one on the spot would also be a big pain, and
basically creates a recommended dependency of a C compiler. We'd rather
keep Jython's sole dependency the JRE.
JRuby and Groovy share this issue, though I've seen some JRuby tutorials
recommend use of ruby's -S argument to run scripts, which totally avoids
the issue. -S is a little like Python's -m but searches PATH instead of
sys.path:
-S look for the script using PATH environment variable
MRI/YARV also have this option so it isn't too foreign to JRuby users.

On a related note I've noticed java.lang.Process seems to always return 0
as the exitValue() when executing a .bat file. This ends up breaking our
test_cmd_line, and any other test running sys.executable and expecting a
non 0 return code