feat(flags): script arguments come after '--'

[ry]

Fixes #3469

[Fenzland]

That's prevent us to build a real command application. Suppose we implement git with deno, we have to use it like these:

git -- --version
git -- add somefile
git -- commit -m 'add somefile'

A new user query helps with git --help will get help of deno.

[lucacasonato]

That's prevent us to build a real command application. Suppose we implement git with deno, we have to use it like these:

git -- --version
git -- add somefile
git -- commit -m 'add somefile'

A new user query helps with git --help will get help of deno.

Not per se - instead of aliasing git to deno git.ts, alias it to deno git.ts -- and your problem is solved.

[Fenzland]

Not per se - instead of aliasing git to deno git.ts, alias it to deno git.ts -- and your problem is solved.

An alias is not a real command, it only works in current shell, when you switch to another shell, or call with other processes such as Deno.run(), it not work. And it's bellyful to let your users to set alias after download your application.

A reasonable way is write an executable file named as command, with content like this:

#!/usr/bin/env -S deno --allow-something

your user download it and put it into /usr/bin or other place in the PATH.
we cannot add -- after the script name by shebang.

[ry]

@Fenzland This works for me

> cat foo.js
#!/usr/bin/env deno --allow-read --

let f = await Deno.open("/etc/passwd");
console.log("f", f);
console.log("args", Deno.args);
> ./foo.js
f File { rid: 3 }
args [ "asdf", "asasdf" ]
>

[ry]

That was on OSX. When I try it on linux I do indeed get an error. Hrm.

Is the issue that env tries to interpret the "--" ?

[nayeemrmn]

@ry You need the -S after env on Linux. But yes @Fenzland the above works due to the fact that if there are missing unnamed args (like the script name) before the --, they are consumed from after the --. So the following syntax is valid: deno <deno flags> -- <script name> <script args>.

The unnamed arg behaviour which allows this isn't really intuitive and I believe #3011 (wrongly closed 😅) was actually reporting against it as a bug. Confused yet?

[ry]

@nayeemrmn -S doesn't work with the GNU coreutil's env that I have.

[nayeemrmn]

@ry Yeah, 8.30+ as I once wrote here denoland/std#545. (It actually never worked with mine either :P) Nevertheless it's the only solution on Linux going forward.

[dubiousjim]

The Linux kernel handles shebangs in a way that's unfriendly to passing more than one explicit argument (the remainder of the line gets passed to the first command as a single argument, together with the name of the file as a second). I guess the Gnu version of env (after a certain version, someone says 8.30+) reparses the shebang line when invoked with -S. Here's a workaround for users who are using Linux kernel and don't have that variant/version of env installed:

Instead of starting your script with:

#!/usr/bin/env deno run --allow-read

(or possibly with a -- appended...) Start it instead with these two lines:

#!/bin/sh
'exec' //"$(type -P deno)" run --allow-read "$0" "$@"; exit 1

What's happening? The first line says to execute the rest of the file as a shell script. When doing so, it will never go further than the second line, so the rest of the file can be JS or TypeScript. When the file is run by deno, the first line will be ignored as a shebang, and the second line (and rest of the file) gets interpreted as JS/TS. So the second line has to be a "polyglot", that is has to make sense both when interpreted as shell and when interpreted as JS/TS.

It makes sense when interpreted as JS/TS because it's just a string 'exec' followed by a comment.

It makes sense when interpreted as shell because the quotes around exec are stripped, and then the rest of the line up to the ; are read as arguments to exec. We include the ; exit 1 at the end in case deno wasn't found or otherwise couldn't be exec'd. We want the shell script to fail rather than try to interpret the rest of the file.

The arguments to exec are:

First, the path to deno (using type -P deno or command -v deno find deno wherever it is in your path, same as running /usr/bin/env deno). We rely on the fact that prefixing the path with two extra //s at the start shouldn't change its meaning. (A different strategy I've seen is to instead start this line with 'true' //; exec ....)

Next we pass arguments run --allow-read to deno. Then "$0" is the name of the script file being executed. The "$@" add in any arguments specified when invoking the script file.

Depending on whether the feature being discussed here is included or reverted (as it is when I write this comment), you might need to insert a -- before the "$@".