This repository was archived by the owner on Mar 21, 2025. It is now read-only.
Repository navigation
This repository was archived by the owner on Mar 21, 2025. It is now read-only.
runWith option #56
Description
As an alternative to having to chmod +x scripts, users could add an option:
"scripty": {
"runWith": "bash"
}The only changes needed would be to add a branch in spawn-script like spawn(options.runWith, [scriptFile].concat(userArgs), options.spawn) and bypass the isExecutable check.
Activity
[-]`runWith` options[/-][+]`runWith` option[/+]texastoland commentedon Jul 27, 2018
👍🏽 I like this. That's an interesting fallback idea. I don't like setting executable permissions. Is there another use case? Would it be
"runWithWin": 'start ""'for Windows? Is there a security concern?micimize commentedon Jul 27, 2018
@texastoland Yes, it also allows the user to not have the shebang. We could also use
.splitfor argument sharing (don't know if this already exists in the"scripty"key):Not sure about windows.
The only attack vector I can think of is that somehow an untrusted agent is only given permissions to run scripty commands and to write / move files, but not the scripty commands or their permissions. They still have to be able to move the scripts though. Very hard to see as more exploitable.
searls commentedon Jul 27, 2018
This seems reasonable. The config option makes sense to me, but even having
bashplus the windows equivalent in this case as a fallback option for non-executable scripts seems like an improvementtexastoland commentedon Jul 27, 2018
I like the config because it could also be
nodeorruby.searls commentedon Jul 27, 2018
Oh, I'm perfectly fine with having the config, I'm just saying that
bashshould be the default fallback when a user does not set onerosston commentedon Jul 27, 2018
Sorry, getting to this later than everyone else, but I have some thoughts/concerns here:
runWithpath here will eventually lead to a per-script version of the same option, and I think that functionality is largely duplicated by the shebang (which comes for free from the OS).chmod +xkeeps the scripts fully functional outside of the context of scripty (and is persisted in source control as @micimize noted in Add "permissions will also be stored in git" note to README #65).Only my 1st point really relates to this project directly. The 2nd and 3rd points are more about the general project good practices, although I might argue that that's part of the point of this project in the first place. 🙂
I'm happy to be overruled here, but I just wanted to get those thoughts out.
texastoland commentedon Jul 27, 2018
👌🏽 I'd only call it in the
elsebranch where we currently log that the file isn't executable.👍🏽 I agree it ought to be there regardless.
😕 also agree but making a bunch of files executable is inconvenient. It's easy enough in terminal. Unless you're new. Or on Windows. I ought to request it in VS Code.
texastoland commentedon Jul 27, 2018
Maybe it'd be better to provide a CLI (with #1) that wraps
fs.chmodfor the script directories?micimize commentedon Jul 27, 2018
@rosston for your first point, I think we can just refuse to add a per-script config, and tell users to solve that problem themselves by using executables, etc.
I think the rest is a matter of taste, or even project specific - I prefer file extensions to shebangs, and might actually prefer discouraging the execution of scripts without
yarnornpmbecause they provide required context for most of my scripts.That said, @texastoland's idea would also address my main concerns, if you guys want to keep the API svelte.
jasonkarns commentedon Dec 18, 2018
My initial reaction to this was 👎 because I initially agreed with @rosston , but @micimize 's comment resonates with me:
However, I've personally found it to be an improvement for a script to accept arguments such that it can be invoked directly. Then the npm context (env vars, etc) can be used to provide the defaults for said arguments.
That said, I'm pretty neutral on this feature.
agirorn commentedon Jul 10, 2019
Could scripty not determine how to run a script based on the file extension if it is not an executable?
searls commentedon Jul 10, 2019
jasonkarns commentedon Jul 17, 2019
The filename mapping seems a plausible fallback if executable bit isn't set and I like that it wouldn't require a bunch of additional configuration.
I still think executable bits are the "correct" setup for most cases. (Indeed, they allow the same script to be ported from, say, bash to node without needing to change the callers.)
But for users who don't want to make them executable, a having a file extension is already the correct approach. So having scripty lean into that is 👍
The only downside is that I'm not super excited about deciding which runtimes we'll consider blessed; for which we'll have automatic extension mappings coded into scripty.
micimize commentedon Jul 20, 2019
I don't think anything should be automatically resolved initially - there are so many
.shrunners.runWithalso serves as a bit of documentation.