-
-
Notifications
You must be signed in to change notification settings - Fork 31.9k
Executable permissions of Python source files #64135
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I like this, and I'm doing this in the Debian/Ubuntu packaging anyway. But I would like to see some check script which maybe can be run before a release, that points out regressions or wrong permissions for newly introduced files. |
New changeset 9062a8695c89 by Stefan Krah in branch '3.3': |
New changeset 92fd0df03823 by Serhiy Storchaka in branch '3.3': New changeset 83009d70bc9c by Serhiy Storchaka in branch 'default': |
Here is a script. It lists text files with executable bits and without shebangs and files with .py, .pyw, or .sh suffix which have shebang but have not with executable bits. As far as it searches not only Python files, now it found such files:
|
Somehow Modules/_decimal/tests/bench.py and Modules/_decimal/tests/deccheck.py are now executable, which (I think) they should not be. |
New changeset 085a0ea2015f by Serhiy Storchaka in branch '3.3': New changeset 6baeee39195b by Serhiy Storchaka in branch 'default': |
New changeset 334116bb2939 by Serhiy Storchaka in branch '2.7': |
Left files with mismatched executable bits and shebangs: Python 3.4:
Python 3.3:
Python 2.7:
|
IMO the .bat files should have the executable bit as a reminder that they're |
Gregory, is it intentional that Modules/_ctypes/libffi/build-ios.sh, Modules/_ctypes/libffi/libtool-ldflags, Modules/_ctypes/libffi/msvcc.sh and Modules/_ctypes/libffi/src/arm/gentramp.sh have no executable bits? They all have executable bits in mainstream libffi-3.0.13 distribution. |
For those four libffi files in msg208964, do what you want with them. I ignored executable bits entirely (didn't set or unset) when importing the code as there is zero need to execute any of them. IMNSHO, I think executable bits should _not_ be set on most files in the Python source tree. *Especially* not on things under Lib and Lib/test/. Afterall, any #! on those is *guaranteed* to not refer to the Python interpreter the source tree represents. |
New changeset 1cfce469642d by Serhiy Storchaka in branch '3.3': New changeset 9adce4e25bdb by Serhiy Storchaka in branch 'default': |
Now findnoshebang.py shows only example files in the documentation, Windows-specific bat and pyw files, generated files, and the Modules/_ctypes/libffi/ltmain.sh file. I have not touched ltmain.sh file which have no shebang nor executable bits in the libffi distribution, because I'm not sure this is safe. Thanks all for reviews. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: