Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Bash Completion Works

tuzz.tech

Post reply on HN
Print view View original

31–40 of 49 posts

Re: How Bash Completion Works

#31

Post by pcr910303 »

SPBS wrote: post #25
nfoz wrote: post #12

I always disable shell completion after it burned me a few times: 1. Completion that blocks the shell, by doing a lookup across a network (e.g. to complete a remote path). Can hang for several seconds. 2. Completion that gives me a misleading/incorrect view of the filesystem, by "intelligently" filtering which files/filetypes it will let me complete. For example, if I have foo.mp3 and foo.txt, and a media-player comm…

Yeah homebrew does that remote lookup thing when I try to complete `brew install xx `. Because of the delay, it's not a good way to discover packages at all especially if the package name has an unexpected prefix that causes bash completion to fail. Much better to just `brew search xx` then browse the entire list of possible candidates than to rely on tab completion.

> Yeah homebrew does that remote lookup thing when I try to complete `brew install xx`.

AFAIK Homebrew doesn't do remote lookup, you can try it out by turning off your Wi-Fi & autocompleting formula names still work.

> Because of the delay, it's not a good way to discover packages at all

The delay is due to ruby's slow speed, it looks like home-brew just searches the whole formula directory with ruby.

Re: How Bash Completion Works

#32

Post by Someone »

TLDR version: duct tape and hundreds of people helping prevent the contraption from falling apart :-)

That’s not the scary part, though. The scary part is that those completion scripts run with the user’s privileges, unsandboxed. I could find only a single CVE (https://www.cvedetails.com/cve/CVE-2018-7738/), but I think it would be wise to sandbox these scripts.

Re: How Bash Completion Works

#33

Post by shakna »

vunie wrote: post #21

My issue with bash completion is that it requires a completion script (i.e executing `complete`) for each command you want it to complete. The shell cannot automatically deduce appropriate completions when possible. This problem is not specific to bash. Fish and other shells can't automatically complete commands either. There is simply no standard way to detect what type of auto-completion a command supports. I know…

> The shell cannot automatically deduce appropriate completions when possible.

I don't think this even _can_ be possible for a large number of programs.

For some small number of programs it _might_ be possible, if somehow (ignoring how for now) you were exposed some standard interfaces like getopt or argparse and didn't have to care about argument ordering.

But a ton of other programs, with extremely complicated interfaces, simply wouldn't be possible. And these include commonly used programs.

Auto-completing awk would require a full language parser at the least, for example.

Another, ffmpeg, has a dizzying array of options, and the order of those options can completely change the intent of the command, and what options are allowed to follow without being ignored silently.

Even if we had perfect interface detection, we could only probably generate a subset of auto-completion options because that particular problem might not _always_ be solveable.

Re: How Bash Completion Works

#34

Post by shakna »

Someone wrote: post #32

TLDR version: duct tape and hundreds of people helping prevent the contraption from falling apart :-) That’s not the scary part, though. The scary part is that those completion scripts run with the user’s privileges, unsandboxed. I could find only a single CVE ( https://www.cvedetails.com/cve/CVE-2018-7738/ ), but I think it would be wise to sandbox these scripts.

If you sandbox, can you actually guarantee completion?

Some more complicated commands might depend on the contents of a file, or the permissions of the file, and an environment variable at the same time to find valid options.

Others may require accessing a list of processes running under the active user, which could only be accessible when running as the user in some circumstances.

Tacking on any kind of permission system will probably break thirty-odd years of programs, and would likely be a hack because of how POSIX is expected to behave.

Duct tape it certainly is, but backwards compatibility isn't something to hate either. We run code all day everyday. That completion runs code shouldn't be a surprise, and you need to judge whether or not you trust it before using it.

Re: How Bash Completion Works

#35

Post by shakna »

techntoke wrote: post #3

Is there anything like completion for ash within Alpine containers, or do you have to install Bash?

I don't believe Almquist ever incorporated tab completion. Korn did, so a number of more limited shells may support it, but probably not ash.

Re: How Bash Completion Works

#36

Post by JoshTriplett »

nfoz wrote: post #12

I always disable shell completion after it burned me a few times: 1. Completion that blocks the shell, by doing a lookup across a network (e.g. to complete a remote path). Can hang for several seconds. 2. Completion that gives me a misleading/incorrect view of the filesystem, by "intelligently" filtering which files/filetypes it will let me complete. For example, if I have foo.mp3 and foo.txt, and a media-player comm…

Regarding 3: I wish that all completions were provided by the programs (ideally by invoking the program) rather than by a hard-coded list in a bash-completion file.

Re: How Bash Completion Works

#37

Post by arianvanp »

JoshTriplett wrote: post #36
nfoz wrote: post #12

I always disable shell completion after it burned me a few times: 1. Completion that blocks the shell, by doing a lookup across a network (e.g. to complete a remote path). Can hang for several seconds. 2. Completion that gives me a misleading/incorrect view of the filesystem, by "intelligently" filtering which files/filetypes it will let me complete. For example, if I have foo.mp3 and foo.txt, and a media-player comm…

Regarding 3: I wish that all completions were provided by the programs (ideally by invoking the program) rather than by a hard-coded list in a bash-completion file.

In haskell the parser library for your cli auto-generated a completion file which is very convenient.

Re: How Bash Completion Works

#38

Post by greggman2 »

vunie wrote: post #21

My issue with bash completion is that it requires a completion script (i.e executing `complete`) for each command you want it to complete. The shell cannot automatically deduce appropriate completions when possible. This problem is not specific to bash. Fish and other shells can't automatically complete commands either. There is simply no standard way to detect what type of auto-completion a command supports. I know…

I'm only guessing this is what PowerShell was supposed to enable. I've never used it but I gather programs are supposed to offer enough metadata to do this?

Re: How Bash Completion Works

#39

Post by hnlmorg »

vunie wrote: post #21

My issue with bash completion is that it requires a completion script (i.e executing `complete`) for each command you want it to complete. The shell cannot automatically deduce appropriate completions when possible. This problem is not specific to bash. Fish and other shells can't automatically complete commands either. There is simply no standard way to detect what type of auto-completion a command supports. I know…

Some shells do parse manages and use other tricks to auto-determine completes. Though they're not POSIX compliant shells so you'd have a to retrain a little there.

I'm interested to know more about that ELF / --_complete trick though. Do you have any more details? (when DDging the only result I can find on the topic is your comment)

Re: How Bash Completion Works

#40

Post by vunie »

hnlmorg wrote: post #39
vunie wrote: post #21

My issue with bash completion is that it requires a completion script (i.e executing `complete`) for each command you want it to complete. The shell cannot automatically deduce appropriate completions when possible. This problem is not specific to bash. Fish and other shells can't automatically complete commands either. There is simply no standard way to detect what type of auto-completion a command supports. I know…

Some shells do parse manages and use other tricks to auto-determine completes. Though they're not POSIX compliant shells so you'd have a to retrain a little there. I'm interested to know more about that ELF / --_complete trick though. Do you have any more details? (when DDging the only result I can find on the topic is your comment)

> (when DDging the only result I can find on the topic is your comment)

You weren't kidding at all.

After spending more time than I'd care to admit searching for the library, I couldn't find traces of it anywhere on google, ddg, or bing. I relented and digged whatever information I could find in my history.

Revisiting these projects, it's painfully obvious that I have jumbled a few projects together. Sincere apologies for the unintended goose chase.

This project [1] is the one that introduced the `--_completion` flag. It registers itself as a default completion function, but blindly and dangerously tries to run any command it gets with this flag. (This project is completely de-indexed from search engines and I'm not sure why).

Like [1], project [2] registers itself as a default completion function, but checks the first 1024 bytes for the magic string "PYTHON_ARGCOMPLETE_OK". It seems to be relying on argparse for completion.

I couldn't manage to find the project that was scanning elf sections. I'm not entirely sure if it was relying on elf sections specifically or if the fact that it was scanning elf sections was only an implementation detail.

[1]: https://github.com/dbarnett/python-selfcompletion [2]: https://github.com/kislyuk/argcomplete

Post reply on HN