This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: OS X: Can't use #!/usr/bin/pythonw
Type: Stage:
Components: macOS Versions: Python 2.4
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: jackjansen Nosy List: bob.ippolito, edemaine, jackjansen, n8gray, ncoghlan
Priority: normal Keywords: patch

Created on 2004-10-02 09:40 by n8gray, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
pythonw.c-and-makefile-patch.txt n8gray, 2004-10-02 09:40 pythonw.c and patch for dist/src/Mac/OSX/Makefile
Messages (7)
msg47008 - (view) Author: Nathan Gray (n8gray) Date: 2004-10-02 09:40
At the moment, on OS X /usr/bin/pythonw2.x is a simple sh script 
that exec's a python interpreter within a valid OS X application 
bundle.  The problem is that this prevents python scripts from 
using pythonw in the #! line.  Darwin won't allow a script to act as 
an interpreter in a #! line.

This patch replaces the shell script with a simple C program that 
does the same thing -- it just calls execv on the python interpreter 
within the OS X app bundle.  Since it is a compiled executable it is 
allowed to act as an interpreter in #! lines.

Your patch guidelines said you preferred multiple patches to be 
concatenated in a single file.  My patch consists of a Makefile 
change and a new file, dist/src/Mac/OSX/pythonw.c.  I've included 
both in the text file attached to this report.  It would probably be 
prudent for somebody to review the Makefile change, since it's 
always tricky to find the right way to put a new file in someone 
else's build process.

Thank you,
-Nathan
msg47009 - (view) Author: Nathan Gray (n8gray) Date: 2004-10-02 09:43
Logged In: YES 
user_id=121553

By the way, the patch is against CVS head.
msg47010 - (view) Author: Nathan Gray (n8gray) Date: 2004-10-03 01:00
Logged In: YES 
user_id=121553

Assigning to Jack Jansen as suggested by Bob Ippolito on pythonmac-sig.
msg47011 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2004-10-04 14:34
Logged In: YES 
user_id=1038590

As described in the python tutorial, the recommended
solution to this is to use the following on the shebang line:

#! /usr/bin/env pythonw

this also has benefit of not caring where python is installed.
msg47012 - (view) Author: Nathan Gray (n8gray) Date: 2004-10-04 20:16
Logged In: YES 
user_id=121553

The issue is that sometimes you *do* care where python is installed, and 
you want to be sure to get the system python and not, for example, the 
Fink python.  At the moment, the only solution is to use a gangly #! line 
like:
#! /System/Library/Frameworks/Python.framework/Resources/
Python.app/Contents/MacOS/Python
and you'll only figure that out if you're clever enough to understand why 
#!/usr/bin/python works but #!/usr/bin/pythonw doesn't.

Mainly, it's just needlessly confusing to have a python interpreter that 
works from the command line but doesn't work in a #! line.  It's 
unfortunate that the distinction between python and pythonw is 
necessary, but as long as it is then it would be nice if at least pythonw 
was able to act as a drop-in replacement for python.  It's pretty simple 
to make it work as expected, so why not do it, for the sake of 
consistency?
msg47013 - (view) Author: Erik Demaine (edemaine) Date: 2006-04-03 16:48
Logged In: YES 
user_id=265183

Is there a good reason why this patch has not been
implemented ?  It seems really strange to me that
#!/usr/bin/pythonw doesn't work (but #!/usr/bin/python and
#!/usr/bin/env pythonw do) because pythonw is made a shell
script.  Perhaps the root problem is that a symlink doesn't
work, which is because of some other flaw in the interpreter
somewhere?
msg47014 - (view) Author: Bob Ippolito (bob.ippolito) * (Python committer) Date: 2006-07-15 16:33
Logged In: YES 
user_id=139309

Python 2.5 solves this problem, but with a solution that does not descend from 
this patch.

Additionally, the need for a python/pythonw distinction at all is solved in Python 
2.5 with framework builds.
History
Date User Action Args
2022-04-11 14:56:07adminsetgithub: 40975
2004-10-02 09:40:42n8graycreate