[kevingadd]

The way they disambiguate between the two options feels like it would have been a ton of work to figure out and implement... and for what purpose? I don't understand the user story here. How hard is it to type the long version?

[MOARDONGZPLZ]

As a user, I don’t want to have to type the full option name every time I use it.

[collingreen]

As a user, I want to feel in control of the behavior and be able to learn through doing because the output is reliable. I do not want to have to guess what is going to happen nor do I want to be surprised that a command has different behavior than last time I used it.

[nerdponx]

GNU solved this problem a long time ago by distinguishing -v and -V.

[forrestthewoods]

As a user I almost never use short flags because it’s super confusing and inscrutable. But I admit I’m probably in the minority on this!

[jonnycomputer]

I use them for simple commands I use all the time when I do interactively. If its a script its long-form all the way. Explicit is better than implicit...

[amelius]

> As a user, I don’t want to have to type the full option name every time I use it.

You don't have to on the command-line, but if you're writing a script then the unwritten rule is that you use the full option name.

(Too bad this isn't enforced)

[WD-42]

If you are typing instead of using tab auto complete or shell history then that’s on you.

[Flop7331]

Your shell should be smart enough autocomplete it anyway.

[BiteCode_dev]

You don't always choose your shell.

[Flop7331]

You don't say. This thread whiffed badly on is vs. ought.

[LoganDark]

Who autocompletes flags? Even as a Fish user, I'm stuck with not-Fish often enough that I can't afford to let it become part of my muscle memory.

Before you say "Bash can autocomplete flags" I don't think I've ever encountered a single third-party shell command that actually packages proper completions.

(Some Rust commands that use `clap` for argument parsing do something to install completions after the first run, but in my experience this is not particularly reliable)

[TheCleric]

Plus while it’s very convenient for tools that support autocomplete of their parameters, but not all do. So sometimes you just fall in the habit of assuming they don’t.

[LoganDark]

My experience with flag autocomplete is like 90% it completing a huge filename that I then have to backspace annoyedly. Not entirely sure which shell I encountered it on but wow. I just can't afford to rely on it because of cases like those.

[moring]

This makes me wonder why shells don't support a simple "undo". Though I think there will be a UI conflict between "undo autocomplete" / "undo paste" / other stuff that edits the current command line, and "undo the last command" which would need much deeper integration with the tools that get run.

[shagie]

How would a shell interrogate the valid parameters from a complied binary?

I know that approaches like Powershell which has understanding of all the Microsoft commands and the ability to define a structure that defines the options ... but how would bash figure out the structure of the arguments for dd or tar or that a.out that I just compiled?

[moring]

By accompanying the binary with a formal description of the possible arguments, either as a separate file or embedded in the executable. But the latter is not really sustainable the more metadata you add, so more likely a separate file.

Applications already come with lots of metadata: man pages, icon, readable name, ... adding formal shell-completion information is just another one.

Besides that, the built-in command line tools already have auto-completion for their arguments. Though I think they do it by running scripts at shell startup, which isn't exactly the mechanism I would have used... but it works.

In your case, "that a.out I just compiled", this metadata would be missing, so no shell completion for you. But that is a niche use case anyway, and not at all what this post is about.

[Flop7331]

I'm kinda surprised this is news to readers here.

[kevingadd]

The default shell on debian autocompletes git commands and things like branch names pretty robustly for me, so somebody figured it out.

[shagie]

That works in similar ways as posh-git ( https://github.com/dahlbyk/posh-git ) - the tooling for Powershell to be able to be able to do things with git.

This has a fair bit of code that goes in and examines the .git directory when present.

Additionally, the shell has been programed to be aware of the git sub commands.

But is it aware of... say... svn sub commands? The same amount of effort would be need to be done to have bash aware of .svn and its sub commands.

This is special tooling written for one suite of commands.

It doesn't work for arbitrary commands or arbitrary data structures. Even well known ones.

    tar -zxvf <tar filename> {specific file}

That doesn't do tab expansion for the specific files that are within the tar file. Nor does doing --f show the expansion options for --file --format --fflags

Someone wrote special case tooling for one shell for one command named git.

[zombiwoof]

Apple engineers know they are the best and don’t care what anyone else says

[amelius]

If they know they are the best, then why do they keep doing slavishly what management tells them instead of building the best products?

[smt88]

Apple may have the best hardware engineers, but Apple software is absolute garbage and I miss Android and/or Windows whenever I have to use it. It is astonishing how buggy and bad iOS is.

[mananaysiempre]

> a ton of work to figure out and implement

Not really?

  while ((opt = getopt(...)) >= 0) switch (opt) {
  ...
  case 'v':
      if (!action) { action = VERIFY; break; }
      verbose++; break;
  ...
  }

(A followup post clarifies that a -v before a different action flag does not retroactively turn into “verbose”; in any case that’s also not hard to do. To be clear, both possibilities suck, I just disagree they’re difficult to implement.)