Hacker News new | ask | show | jobs
by Flop7331 674 days ago
Your shell should be smart enough autocomplete it anyway.
3 comments

You don't always choose your shell.
You don't say. This thread whiffed badly on is vs. ought.
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)

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.
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.
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.
They do:

- PowerShell has Ctrl+Z

- Bash has Ctrl+/

- Fish has Ctrl+Z and Ctrl+/ both

not sure about others, surely if you're using busybox ash this won't work (no line editing will work), but I'm sure most shells have some sort of undo, as long as they have any line editing at all.

I just looked it up and for zsh (MacOS default) it’s Ctrl+_

Hopefully I’ll remember that next time I need it.

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?

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.

I'm kinda surprised this is news to readers here.
The default shell on debian autocompletes git commands and things like branch names pretty robustly for me, so somebody figured it out.
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.