Hacker News Reader

Comment by kzrdude | Hacker News Reader

The GNU conventions are terribly convenient. If we were redesigning it from scratch, I'd like to keep all of them except for removing duplicated functionality. One of --long x and --long=x have to go, and that means we only can keep --long=x. And so on.

View on HN

I disagree with getting rid of `--long x`. It's really common to build command argvs programmatically, where you have a string representing some option (such as a file path), and you need to pass that as a long option. With `--long x`, you can do like:

    char *argv[] = {"my-program", "--config-file", config_file, NULL};
    run_command(argv);

With only `--config-file=x`, you would have to allocate memory for the option:

    char *config_file_opt = asprintf("--config-file=%s", config_file);
    char *argv[] = {"my-program", config_file_opt, NULL};
    run_command(argv);
    free(config_file_opt);

And it becomes even more hairy if you A) want to avoid heap allocation in most cases or B) want to use standard functions rather than asprintf. You'd have to do something like this:

    char config_file_opt_buf[1024];
    char *config_file_opt;
    size_t config_file_opt_len = snprintf(config_file_opt_buf, sizeof(config_file_opt_buf), "--config-file=%s", config_file);
    if (config_file_opt_len >= sizeof(config_file_opt_buf)) {
        config_file_opt = malloc(config_file_opt_len);
        snprintf(config_file_opt, config_file_opt_len, "--config-file=%s", config_file);
    } else {
        config_file_opt = config_file_opt_buf;
    }

    char *argv[] = {"my-program", config_file_opt, NULL};
    run_command(argv);
    if (config_file_opt != config_file_opt_buf) {
        free(config_file_opt);
    }

And even that ignores any kind of error checking of snprintf or malloc which may fail. I also wouldn't even be comfortable assuming the code I just wrote is correct, without thinking long and hard about it and reading standards/documentation thoroughly. Whereas the first example is so simple it's obviously correct.

I think we should keep `--long x`. If anything, `--long=x` is the one which should go. There will always be ambiguity; the meaning of something like `-ab` also depends on whether `-a` takes an argument or not.

Really though, I think there are enough situations where `--long=x` is useful that I think keeping both versions makes sense.

If all of this matters so much, don’t use an (interactive) shell.

We're not talking about the shell, we're talking about the options parser. Nothing in my examples invokes any shell.

Sure, but who calls your main()? Usually when you're in a shell, which in turn calls exec and copies over some data.

If you're that worried about performance about a few string allocations, you shouldn't be passing around strings anyway, shell or not.. And simply call functions from the same process and use for example the file descriptors you already have.

You could also just simply pass a binary blob (messagepack) as one of the arguments, if that's your thing.

You're about to spawn a new process, you can't honestly be worried about a string allocation.

The fact that this is cumbersome in C is fixed by fixing C, not by forcing a pattern onto the ecosystem that only makes sense to work around C's deficiencies.

I don't think C makes this especially cumbersome, most languages make it somewhat complicated to do format-printing (or string concatenation) into a stack-allocated buffer if it's big enough or fall back to heap-allocating a buffer if the stack buffer is too small.

The argument that you should just heap-allocate because it usually doesn't matter in contexts where you'd spawn a process anyways is a much better argument though. Still, I find the `{"whatever", "--config-file", config_file}` approach much more elegant.

I'll add another minor reason: `--foo="bar"` (with quotes) relies on the quoting/splitting behavior of the shell, which is easy to forget.

For example, someone might write:

    args = [cmd, f'--foo="{foo}"']

and expect the surrounding quotes to be stripped off, but that'll only happen if the spawn goes through a shell first. Some argument parsers may also try to strip quotes off, but I don't believe there's any consistent behavior guaranteed around that.

I am annoyed go's flags package did not respect the GNU convention for options, which I agree is the best.

I am not too surprised that the confluence point between Plan 9 and Google have little interest in following the GNU way.

Plan 9 did nothing wrong.

Try github.com/spf13/pflag, it handles double-dash arguments OK, and is drop-in.

> that means we only can keep --long=x

Just wondering: why `--long=x` over `--long x`?

`--long x` is potentially ambiguous. `x` could be referring to a file if `--long` doesn't take any options, so parsing it correctly depends on this knowledge. The equals sign removes this ambiguity.

If we were starting from scratch, we could require some marker on flags which take values. Perhaps it would have to be `--long: x`. `--verbose x` would be read as a flag with no argument, followed by a positional argument.

Isn’t that just replacing “=“ with “:”?

No, there's a space in there too!

This works to allow values to be optional while not requiring concatenation of strings in languages where that's troublesome like C.

It only lacks in being able to work with brace expansion to facilitate specifying multiple values.

--long=x supports the simultaneous --color and --color=auto usecase, i.e the value is optional. Without = it's ambiguous.

It also has the advantage that it works with brace expansion to specify multiple values.

--long={foo,bar}

becomes

--long=foo --long=bar

Thanks for teaching something useful!

Actually you can expand any pattern:

  --option{X,Y}   ->  --optionX --optionY
  --option:{X,Y}  ->  --option:X --option:Y
  ...

With bash/zsh the auto-completion seems missing for unknown options. While `--key file` supports auto-completion since file is just another parameter.

Yup. Both styles have their advantages, which is why they're both common.

For the problem you mention, I normally have them separate while I use completions, then add the = sign after.

that's a tool issue that should be fixed

I’m curious why they introduced the ‘=‘ variant at all. Maybe they thought it would be clearer for human readers?

Sometimes I'm glad for public interface ossification. :)

Still waiting for su —-with-wheel-group

I come not to bury wheel, but to praise it.

An industry big wheel, a wheel man with nice wheels, put shoulder to the wheel to put wheels in motion spinning wheels to reinvent the wheel before the wheels came off the wagon and squeaky wheel gets the grease. My name is Jonas. I'm carrying the wheel.

I confess that back in the day, whenever I tried to grok a man page or manual page about wheel, it was basically incomprehensible.

Reply on news.ycombinator.com