init: When writing hook scripts, set all execute bits, not only the user execute bit

This commit is contained in:
Joey Hess 2020-11-17 13:31:12 -04:00
parent fbbc42a9d4
commit 6b63278f31
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
3 changed files with 15 additions and 2 deletions

View file

@ -7,6 +7,8 @@ git-annex (8.20201117) UNRELEASED; urgency=medium
branches set up by git-annex adjust --unlock-present/--hide-missing.
* examinekey: Added a "file" format variable for consistency with find,
and for easier scripting.
* init: When writing hook scripts, set all execute bits, not only
the user execute bit.
-- Joey Hess <id@joeyh.name> Mon, 16 Nov 2020 09:38:32 -0400

View file

@ -55,8 +55,9 @@ hookWrite h r = ifM (doesFileExist f)
f = hookFile h r
go = do
viaTmp writeFile f (hookScript h)
p <- getPermissions f
void $ tryIO $ setPermissions f $ p {executable = True}
void $ tryIO $ modifyFileMode
(toRawFilePath f)
(addModes executeModes)
return True
{- Removes a hook. Returns False if the hook contained something else, and

View file

@ -20,3 +20,13 @@ git-annex version: 8.20201103, on Debian sid
### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
git-annex is super great :-)
> That's a bug indeed! I've fixed it.
>
> I decided to not make re-running `git-annex init` fix up the file mode
> if the hook already existed with the wrong permissions.
> That seemed like probably a bad idea, because it's at least possible
> the user might intend to unset one of the x bits and git-annex should not
> get in the way of that. So, you should `chmod a+x` the hooks yourself.
>
> [[done]] --[[Joey]]