Deno: Flag order error

[Soremwar]

While using special permissions it is necessary to use "allow flags" to properly access network, files, etc. However while using this flags on the CLI it is necessary to use this flags before the file we're going to run, otherwise it won't apply them.

Ex:

I can understand this behavior might be intended but it can be really annoying, since it differs from the common use of flags on CLI commands accross different OS environments. Also it differs from the examples provided about Deno Install (which I have not personally used).

I've run into this issue(?) while using v0.25 on Windows, Linux(Manjaro) and Linux(ElementaryOS).

[musaprg]

Is this duplicate of https://github.com/denoland/deno/issues/2708 ?

[nayeemrmn]

See #2798 and #3138. Since recently, everything after the script name gets passed to the script. What's annoying is not being able to easily pass common flags to scripts because they may or may not get consumed by Deno. It's more reasonable this way.

The examples for deno install are correct. deno install still works like this (I hope). It doesn't take runtime args so there's no confusion.

[Soremwar]

Just read #2798 and #3138.

Seems reasonable. Though I would make use of a separate flag for script arguments as many CLI programs do. It's more than just incomfortable, is following an unwritten standard for cli.

Maybe it's just me. But
deno app.bundle.js --allow-net --allow-read -args arg1 arg2
seems just better than
deno --allow-net --allow-read app.bundle.js arg1 arg2
or at least more readable.

[nayeemrmn]

Maybe it's just me. But
deno app.bundle.js --allow-net --allow-read -args arg1 arg2
seems just better than
deno --allow-net --allow-read app.bundle.js arg1 arg2
or at least more readable.

It's readable because your script args are named arg1 arg2. If your script took args like --allow-logging or --version, how would those examples look?

[Soremwar]

It's readable because your script args are named arg1 arg2. If your script took args like --allow-logging or --version, how would those examples look/work?

That's the point. An specific -arg or --args flag is intended to do that kinda examples more readable.

I see why leaving the access flags before the script is necessary with the current configuration, but using a flag to specify what the --version flag(or whatever CLI args we would want to pass as variables) seems more convenient.

deno --allow-net app.bundle.js -args= --version
or
deno app.bundle.js --allow-net -args= --version

seem clearer than

deno --allow-net app.bundle.js --version

[ry]

We could require that script args are placed after -- so it would be

deno -A https://deno.land/std/http/file_server.ts -- /etc

This would allow for better error checking of the flags...

[Soremwar]

I saw the use of -- in #3138, however it still seems unclear(If we are talking strictly about readability here).

-args or -args= seems clear enough and just like -- removes the need of using access flags only before script route.

EX (for comparison):

Proposal:
deno date_app.js --allow-read --allow-net -args= 201901 201912 --version

Ryan proposal:
deno --allow-read --allow-net date_app.js -- 201901 201912 --version

Current use:
deno --allow-read --allow-net date_app.js 201901 201912 --version

I go for better command readability

[bartlomieju]

Ref #3621

[mathiasrw]

Was #3621 meant to fix this issue? Using deno 0.30.0 I still cant place the deno flags after the filename:

deno a.ts --allow-net
error: Uncaught PermissionDenied: run again with the --allow-net flag

[nayeemrmn]

@mathiasrw That was reverted in #3681.

Is there some reason people want to put flags after the script name? It's been said here that it's an "unwritten standard" but I don't see that being the case. That's not how it would work for shebangs or for aliasing. That's not how I see Makefiles being written.

IMO the way it works now follows really simple logic and I haven't seen a use case it doesn't satisfy.

[isAdrisal]

@nayeemrmn I can't speak for others, but for me having flags after the script name is much clearer logic.

"I want to run example.ts with these --permissions and these -arguments"

as opposed to:

"I want to run these --permissions with example.ts using these -arguments"

[mathiasrw]

@nayeemrmn Thats all good for me, but I do suggest that its more clear in the documentation.

Or even better, when the user gets the warning it looks at if the flags where set somewhere and let the user know if they shuold move them.

Ahh - might be too much work for a tiny issue. Anyway. The input has been given.

[nayeemrmn]

"I want to run example.ts with these --permissions and these -arguments"

as opposed to:

"I want to run these --permissions with example.ts using these -arguments"

@isAdrisal Trying to map the command to a spoken sentence has nothing to do with logic, there are always ways of saying both (though people often deliberately mess up the grammar for the one they don't like). I'm talking about things like having the script name next to the script args, having the deno flags next to the subcommand they might be specific to, and other practical benefits which caused #3621 to be reverted.

[nayeemrmn]

@ry Maybe we could use the -- for the opposite, to stop reading script args:
deno <deno flags> <script> <script args> -- <more deno flags>
So for interactive terminal usage it's easy to append permissions/config if you forget any. And people that want to put deno flags afterwards can do so but be the ones to put up with -- 😁

[dubiousjim]

@nayeemrmn Please no, because I want to be able to pass -- more args to my <script>. On @ry's proposal (also without deno handling -- in any special way), I can still do that. On Ryan's proposal (merged in #3621 , reverted in #3681) it would look like:

deno <deno flags> <script> -- <early script args> -- <late script args>

The first -- is a signal to deno, but the second one still gets passed to my script. On the strategy @nayeemrmn's proposing, it's not clear how to do that.