Makopo/lslint

Add chmod fix to "archive_lslint.sh"?

Closed this issue ยท 11 comments

To prevent having to use the following workaround:

https://github.com/Makopo/sublime-text-lsl/blob/e50c37795ef16c4703412e0f89f3791eaf58f3cf/init.py#L1-L18

on Linux and macOS maybe archive_lslint.sh could be update to implement the fix right away?


/cc @thickbrick

This script is just for use on my own, not related to sublime plugin.
If others are confused by its existence, I'll delete the script, should I? @XenHat @Sei-Lisa

I'm OK with its existence. I'm not sure what the complaint is here. Does the binary that is zipped lack exec permissions? That would be weird.

On Linux, unzipping one of the released zips properly sets permissions of the executable to a+x. If that's not the case for someone, that's a problem with whatever is used to unzip the package.

No need to delete anything.

--

I added the binaries to a repo of a Sublime package. Package Control downloads an archive of the latest tag from Github and unpacks that. Looking at https://github.com/wbond/package_control/tree/master/package_control/downloaders there are multiple ways this can be achieved depending upon OS and connection.

On buildersbrewery/sublime-lsl#1 @thickbrick implied it might be enough to set the perms right away. I don't know though as I use neither macOS nor Linux. Hence my question/proposal above.

Do the perms have to be set on the target machine or can that happen before?

I unzipped on Windows using the 7zip beta x64 from the releases page, if that makes a difference

So, I've checked in more detail. The problem seems to be that your (@buildersbrewery) repository doesn't have the lslint binary marked as executable: cloning it, I get a non-executable binary. I have no idea how to do that from Windows, because from Linux the permissions are read directly from the filesystem. I guess Google knows the answer.

As a side note, you seem to have a bunch of files that should be binary marked as text=auto. That includes *.pyc files and some libraries. They were causing problems for me; for some reason the LF conversion is performed in all of them. I'd advise to add *.pyc, *.a, *.la, *.dylib, *.so, *.so.*, *.exe (edit: and *.gz) to your .gitattributes. It doesn't seem possible to do it with something more general like bin/**because of the *.h files.

Will have a look around. Thanks for the input.

I think git update-index --chmod=+x should work on windows to set the unix permissions stored in the git repo (since windows filesystems don't store those.)

BTW @buildersbrewery , the same is needed for the mcpp binaries in your repo (but there are other issues with them too.)

This link may be helpful: https://stackoverflow.com/questions/21691202/how-to-create-file-execute-mode-permissions-in-git-on-windows

There's more than one way to skin that dog. But the basic premise is the same: you have to mark the file as executable in git and then commit and push. That should mark it as executable also in the zipped version that github offers, and I believe that should fix the problem. Same goes for mcpp, as thickbrick points out.

By the way, I think this issue can be closed. It doesn't affect lslint in any way.

Ok, so I'll do this to all binary files with the extensions listed above.

It would've been nice if this was possible in a permanent way when making the files here, though. But I guess I understood that wrong in the beginning.