Skip to content
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

Mark files as executable that are meant as scripts. #15354

Merged
merged 1 commit into from
Sep 9, 2019

Conversation

gnprice
Copy link
Contributor

@gnprice gnprice commented Aug 21, 2019

This is the converse of GH-15353 -- in addition to plenty of
scripts in the tree that are marked with the executable bit
(and so can be directly executed), there are a few that have
a leading #! which could let them be executed, but it doesn't
do anything because they don't have the executable bit set.

Here's a command which finds such files and marks them. The
first line finds files in the tree with a #! line anywhere;
the next-to-last step checks that the first line is actually of
that form. In between we filter out files that already have the
bit set, and some files that are meant as fragments to be
consumed by one or another kind of preprocessor.

$ git grep -l '^#!' \
  | grep -vxFf <( \
      git ls-files --stage \
      | perl -lane 'print $F[3] if (!/^100644/)' \
    ) \
  | grep -ve '\.in$' -e '^Doc/includes/' \
  | while read f; do
      head -c2 "$f" | grep -qxF '#!' \
      && chmod a+x "$f"; \
    done

This is the converse of pythonGH-15353 -- in addition to plenty of
scripts in the tree that are marked with the executable bit
(and so can be directly executed), there are a few that have
a leading `#!` which could let them be executed, but it doesn't
do anything because they don't have the executable bit set.

Here's a command which finds such files and marks them.  The
first line finds files in the tree with a `#!` line *anywhere*;
the next-to-last step checks that the *first* line is actually of
that form.  In between we filter out files that already have the
bit set, and some files that are meant as fragments to be
consumed by one or another kind of preprocessor.

    $ git grep -l '^#!' \
      | grep -vxFf <( \
          git ls-files --stage \
          | perl -lane 'print $F[3] if (!/^100644/)' \
        ) \
      | grep -ve '\.in$' -e '^Doc/includes/' \
      | while read f; do
          head -c2 "$f" | grep -qxF '#!' \
          && chmod a+x "$f"; \
        done
Copy link
Contributor

@epicfaace epicfaace left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do the .wpr files need to be executable?

@gnprice
Copy link
Contributor Author

gnprice commented Aug 24, 2019

Do the .wpr files need to be executable?

Good question!

I took a look at those when preparing this, because I wasn't sure what they were or why they apparently had #! lines.

Here's one of them, which is representative:

$ cat Misc/python-wing5.wpr
#!wing
#!version=5.0
##################################################################
# Wing IDE project file                                          #
##################################################################
[project attributes]
proj.directory-list = [{'dirloc': loc('..'),
                        'excludes': [u'.hg',
                                     u'Lib/unittest/__pycache__',
                                     u'Lib/unittest/test/__pycache__',
                                     u'Lib/__pycache__',
                                     u'build',
                                     u'Doc/build'],
                        'filter': '*',
                        'include_hidden': False,
                        'recursive': True,
                        'watch_for_changes': True}]
proj.file-type = 'shared'

There sure is a #!wing line at the top, and it seems unlikely it's an accident. If it's not simply an accident, then the one effect of choosing to write the file that way is that simply Misc/python-wing5.wpr will have the same effect as wing Misc/python-wing5.wpr. (For example, that might open the given project in the Wing IDE.) But if the file isn't executable, then that effect is defeated. So, if the #! isn't simply an accident, then these files are indeed intended to be executable.

I don't think it's worth spending a lot of time thinking about these particular three files, though -- so if people don't find that convincing, then I'm happy to take that out and proceed with the other 8 files in this PR. Those other 8 files are all Python scripts.

@gnprice
Copy link
Contributor Author

gnprice commented Aug 24, 2019

(Also, the last time any of them was edited was 2013, in e28bb15... and it looks like Wing itself moved on to version 6 in 2016, and version 7 this year, while the latest of these is for version 5. So it seems unlikely that anyone is actually using them today. In light of that I think probably the best thing to do with those three files Misc/python-wing[345].wpr is to delete them; they'll always be in the Git history for reference if needed in the future.

But until/unless we decide to do that I think it makes sense to mark them executable for the reasons above. And in any event, as I said, I'm most interested in the other files in this PR.)

Copy link
Contributor

@epicfaace epicfaace left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, that makes sense. It seems good to make the .wpr files executable, then.

@gnprice
Copy link
Contributor Author

gnprice commented Sep 10, 2019

Thanks @epicfaace for the review, and @Yhg1s for the merge!

@gnprice gnprice deleted the pr-mark-executable branch September 10, 2019 05:28
websurfer5 pushed a commit to websurfer5/cpython that referenced this pull request Jul 20, 2020
This is the converse of pythonGH-15353 -- in addition to plenty of
scripts in the tree that are marked with the executable bit
(and so can be directly executed), there are a few that have
a leading `#!` which could let them be executed, but it doesn't
do anything because they don't have the executable bit set.

Here's a command which finds such files and marks them.  The
first line finds files in the tree with a `#!` line *anywhere*;
the next-to-last step checks that the *first* line is actually of
that form.  In between we filter out files that already have the
bit set, and some files that are meant as fragments to be
consumed by one or another kind of preprocessor.

    $ git grep -l '^#!' \
      | grep -vxFf <( \
          git ls-files --stage \
          | perl -lane 'print $F[3] if (!/^100644/)' \
        ) \
      | grep -ve '\.in$' -e '^Doc/includes/' \
      | while read f; do
          head -c2 "$f" | grep -qxF '#!' \
          && chmod a+x "$f"; \
        done
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants