Deno: support command-line args with only one dash

[ry]

Golang style. So we should be able to do

deno -allow-net server.js

[kitsonk]

Not sure why you are thumbs down on that @hayd. The very arbitrary ness of -- and - is unergonomic really. Single letters will never collide with full ones anyways, and the logic and totally disambiguate it, so I am not sure what -- really signifies other than a really old convention. I can't see a downside to allowing both - and --.

[kevinkassimo]

@kitsonk I am also a bit in doubt of - for long command line args, as I do feel it is a common case to combine multiple single-char flags in the format such as ls -al. Some of our arg names are quite short, such as --deps. Reducing it to -deps would limit our ability to introduce other short flags.

[hayd]

Personally I just don't see what value this adds... and I like the - short -- long convention.

[ry]

I like it because its simpler and less to type.

Here are other discussions:

"Traditionally, UNIX command-line options consist of a dash, followed by one or more lowercase letters. The GNU utilities added a double-dash, followed by a complete word or compound word."

http://tldp.org/LDP/abs/html/standard-options.html

The Go flag package's command lines adopt the observation made by the Google C++ command line flag parser (https://gflags.github.io/gflags/): the long/short --/- two-names-for-every-flag dichotomy was useful for backwards compatibility when recreating original Unix commands, but for new programs, it doesn't pull its weight. At the cost of requiring that each option be specified with a separate command-line argument, you can drop the distinction between - and -- entirely. (This is similar to what X11 programs do, although I believe they do not admit --x as a synonym for -x.)
It's not clear to me what is "ugly" about not having to keep alternating between - and -- as you spell out options on the command line.

Rob Pike, https://news.ycombinator.com/item?id=9206782

[hayd]

At the cost of requiring that each option be specified with a separate command-line argument

I'm happy with this compromise!

[rsp]

Does it mean that if in the future we have e.g. -w, -n and -e shortcuts for --allow-write, --allow-net and --allow-env (which I hope we will as those options will be used pretty often) then we won't be able to use:

deno -wne x.ts
but only:
deno -w -n -e x.ts

because we want to use
deno -allow-write -allow-net -allow-env x.ts
instead of:
deno --allow-write --allow-net --allow-env x.ts
because it's less to type?

Combining single-letter options is even less to type, much less.

I don't know about other people but personally I always write:
ls -alp
instead of:
ls -a -l -p
and I like it even if that makes:
ls --all -l --indicator-style=slash
longer than:
ls -all -l -indicator-style=slash
because I never use the last one in the first place, exactly because I want to have less to type.

I don't really understand this decision because it really is more to type for short options and because it is contrary to the convention and user expectations.

But my other concern is that if we cannot combine single-letter arguments, then we won't be able to write command-line scripts easily with shebang lines (see issue #929) like this:

#!/usr/local/bin/deno -wn

Keep in mind that both this:
#!/usr/local/bin/deno -w -n
and this:
#!/usr/local/bin/deno -allow-write -allow-net
simply would not work at all, unless Deno breaks even more conventions and parses the first argument with spaces in a special way unlike any other tool I know, which will introduce even more problems.

[ry]

@rsp You're concerned about the ergonomics - I think #1008 solves this without having to add extra CLI arguments.

[rsp]

@ry #1008 is very nice for interactive uses. Here I am concerned specifically with scripts and shebang lines that don't support multiple arguments unless those are single letter arguments glued together (everything in shebang after first space, even if there are other spaces, is passed as one argument so #!/bin/deno -x -y is like #!/bin/deno "-x -y"). Without being able to glue arguments we'll have to do tricks like:

#!/bin/sh
":" //#; exec /bin/deno -x -y "$0" "$@"
// ... ts code here

instead of:

#!/bin/deno -xy
// ... ts code here

Not that it's impossible but it may be conrary to some people's expectations, plus it gets through another interpretter before dropping privileges so it may have security implications.

[hayd]

Presumably the way Go is able to get around this is since it only exports binaries (#986) rather than executable scripts (#929). Deno probably wants to support both.

[ry]

@rsp I'm not sure I understand... I'm quite sure that shebangs can take multiple arguments. And it's usually used with /usr/bin/env...

[rsp]

@ry I don't know if that's the case on every system (or with every interpreter because I think Deno could split its argv[1] if it starts with a dash and contains whitespace), but I remember using /usr/bin/env I always had to use some tricks like the one above to pass even one argument to the interpreter (as the interpreter name after /usr/bin/env is passed as an argument to env itself).
I'll see if I can find any reference to that.

Update:
There's some info and examples here:

• https://en.wikipedia.org/wiki/Shebang_(Unix)#Portability
• http://mail-index.netbsd.org/netbsd-users/2008/11/09/msg002388.html

[ry]

I will give up on this for now.

1080 landed support for getopt flag parsing. It's out of scope for us now.

[kevinkassimo]

Switched to getopts for flag parsing, which also supports long_only settings that basically:

Set or clear "long options only" mode.
In "long options only" mode, short options cannot be clustered together, and long options can be given with either a single "-" or the customary "--". This mode also changes the meaning of "-a=b"; in the ordinary mode this will parse a short option "-a" with argument "=b"; whereas in long-options-only mode the argument will be simply "b".

So single dash is still doable, but there will be -help flag collision between v8 and deno, as currently we would do v8_set_flags before getopts ourselves, meaning that the flag would be consumed by v8 to print same stuff as —v8-options

[kitsonk]

Any easy way to intercept and "slice" out -help? People who need to can use -v8-options.

[bartlomieju]

With new CLI using Clap this issue is outdated, let's close it. CC @ry

[danbulant]

I'm quite sure that shebangs can take multiple arguments

That's only on some platforms, but most linux distros support only single argument (like Debian and probably most Debian based).