`runWith` option about scripty HOT 14 OPEN

Sorry, getting to this later than everyone else, but I have some thoughts/concerns here:

• What happens in the case where a user would like some scripts to run with one executable and some with another? It seems like going down the runWith path 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).
• The shebang nicely documents in the script itself what the runtime should be, so that someone looking at scripts in a project doesn't need to know the additional context of how scripty is running them.
• Similar to the above point, chmod +x keeps the scripts fully functional outside of the context of scripty (and is persisted in source control as @micimize noted in #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.

from scripty.

👍🏽 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?

from scripty.

@texastoland Yes, it also allows the user to not have the shebang. We could also use .split for argument sharing (don't know if this already exists in the "scripty" key):

let [ runWith, ...prefixArgs ] = options.runWith.split(/\s+/)
spawn(runWith, [ ...prefixArgs, scriptFile, ...userArgs], options.spawn)

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.

from scripty.

This seems reasonable. The config option makes sense to me, but even having bash plus the windows equivalent in this case as a fallback option for non-executable scripts seems like an improvement

from scripty.

I like the config because it could also be node or ruby.

from scripty.

Oh, I'm perfectly fine with having the config, I'm just saying that bash should be the default fallback when a user does not set one

from scripty.

What happens in the case where a user would like some scripts to run with one executable and some with another?

👌🏽 I'd only call it in the else branch where we currently log that the file isn't executable.

The shebang nicely documents in the script itself what the runtime should be

👍🏽 I agree it ought to be there regardless.

chmod +x keeps the scripts fully functional outside of the context of scripty

😕 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.

from scripty.

Maybe it'd be better to provide a CLI (with #1) that wraps fs.chmod for the script directories?

from scripty.

@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 yarn or npm because 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.

from scripty.

My initial reaction to this was 👎 because I initially agreed with @rosston , but @micimize 's comment resonates with me:

actually prefer discouraging the execution of scripts without yarn or npm because it's they provide required context for most of my scripts.

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.

from scripty.

Could scripty not determine how to run a script based on the file extension if it is not an executable?

• use bash for scripts/script.bash
• use nodejs for scripts/script.js
• use cmd for scripts/script.cmd

from scripty.

from scripty.

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.

from scripty.

I don't think anything should be automatically resolved initially - there are so many .sh runners. runWith also serves as a bit of documentation.

from scripty.