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

Add support for extension-less shell scripts #94

Merged
merged 1 commit into from
Feb 25, 2020
Merged

Add support for extension-less shell scripts #94

merged 1 commit into from
Feb 25, 2020

Conversation

relikd
Copy link
Contributor

@relikd relikd commented Feb 24, 2020

If we want it.
Adding public.unix-executable to the list of data types will allow us to inspect shell scripts that have no extension. For the few exectuables I have tested that were not human readable, QL displayed the "exec"-Icon instead (accordingly). Have not tested a lot of executables though…

@tsdorsey
Copy link
Collaborator

What does it do for binary executables?

@relikd
Copy link
Contributor Author

relikd commented Feb 25, 2020

Actually, you can try the changes with the existing release.
Just modify the plist and qlmanage -r && qlmanage -r cache && killall Finder.
Then wait 5 seconds and try on a shell script first, to make sure it works.

shell script:
shell script

binary executable:
binary executable

@tsdorsey
Copy link
Collaborator

Great, thanks for the info. I think this is fine to merge but I cannot find public.unix-executable in Apple's documentation.

A search reveals a few StackOverflow conversations that mention it but not directly. What defines this UTI?

@relikd
Copy link
Contributor Author

relikd commented Feb 25, 2020

Honestly, I have no idea. I just tried mdls on a windows exe and it did return
public.executable and com.microsoft.windows-executable. Whereas all standard Mac executables have public.executable and public.unix-executable (regardless of readable or not).
Speaking of windows executables. .cmd, .vbs and .batch files are not recognized by mdls at all, but who really needs them anyway…

And eventhough the kMDItemContentTypeTree shows both public.(unix-)executable entries, the resulting type kMDItemContentType uses the more specified version. I guess it won't work with public.executable alone as thats the problem we have with arbitrary extensions and dynamic types. … Actually, I just verified my claim and it indeed does not work with public.executable alone.

@tsdorsey tsdorsey merged commit 9ffd24e into whomwah:master Feb 25, 2020
@tsdorsey
Copy link
Collaborator

Thanks for the footwork @relikd
I don't have time to build a release at the moment but I've merged this so it goes out with the next one.

@porg
Copy link

porg commented May 25, 2020

In QLStephen.qlgenerator 1.5.1 the feature does NOT work

Actual: In Finder opening the QuickLook for my extension-less executable shell script results in the graphical overview (icon + basic file metadata as depicted in relikd's comment above)

Expected: QLStephen QuickLook which shows me the source code of the shellscript.

Research:

$ mdls ~/bin/my/myShellscript 
kMDItemContentType = "public.unix-executable"   
kMDItemFSSize = 2347
$ qlmanage -m | grep public.unix
  • Returns nothing! For some reason QLStephen is not handling the UTI "public.unix-executable"

@relikd
Copy link
Contributor Author

relikd commented May 26, 2020

1.5.1 does not include this feature yet. 1.5.1 was realeased on Feb 5. This feature was merged on Feb 25. We'll have to wait until @tsdorsey packages a new release ;)

Until then you can click above on "Files changed" to see what file has changed and apply the change yourself. That will work without recompiling or changing anything of the binary.

@porg
Copy link

porg commented May 26, 2020

Thanks for your info. I'll await the official release for now. Should I need the feature urgently I will kindly take your workaround hint. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants