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
Resholve doesn't seem to resholve shebangs #15
Comments
"do something smarter" seems like a good goal. :) 2 things make me leery of committing until I have a good handle on how to do this:
The obvious approach seems to be a resholve feature we could think of as a obvious: add something like a checkedPatchShebangs to resholve
Error if any shebang is presentThe user will need a triage API to instruct resholve to ignore the shebang (swallow the error) or specify an interpreter (relative? absolute?) so resholve can lop off all existing shebang lines and write a new one. (Maybe also support specifying a new custom shebang from scratch?)
Find an existing standalone tool that can wrangle any complexity hereI've looked a bit and didn't find anything obviously up to the task, but that doesn't mean one doesn't exist. Refactor patchShebangs to support adding a
|
https://www.in-ulm.de/~mascheck/various/shebang/ was my reference for https://github.com/shlevy/long-shebang. As far as I know, long-shebang and nix's shebang mechanism are the only tools that use multiple lines. shebangs are moderately thorny, but I do think the complexity is ultimately tractable and I doubt it will grow further in the future. |
@shlevy Good to know it's tractable! :)
I haven't specifically tried to survey for nonstandard shebangs, but I noticed a similar project from spack: https://github.com/spack/sbang.
(Can skip this para if you're familiar with what resholve does) In case more context is helpful, resholve tries to find references to relative external executables/scripts, and either resolve them to absolute paths (from directories in the RESHOLVE_PATH) or raise an error if it can't. I think @grahamc is imagining something like
into
My treadmill worry is less (but still a little!) about the core syntax getting harder, and more about the parsing and resolution scenarios getting a lot thornier each step down the slope. For example, consider what the user might expect if they call
Given resholve's value-prop, they probably expect it to go one more step down the slope:
That isn't incrementally too bad, but my treadmill worry is a few small reasonable steps leading users to ask for stuff that'll make me want to tear my hair out (i.e., can't really be supported without full shell parsing for each shebang line). This example isn't very sensible:
But it does run!
|
Furthermore, if the shebang can't be rewritten in to an absolute path, maybe fail unless it is explicitly authorized.
The text was updated successfully, but these errors were encountered: