`runWith` option

[micimize]

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.

[texastoland]

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

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

[searls]

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

[texastoland]

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

[searls]

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

[rosston]

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 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]

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.

[texastoland]

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

[micimize]

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

[jasonkarns]

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.

[agirorn]

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

[searls]

@jasonkarns?

…

On Jul 10, 2019, at 5:01 AM, Ægir Örn Símonarson ***@***.***> wrote: 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 — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[jasonkarns]

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]

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