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

11–20 of 49 posts

Re: How Bash Completion Works

#11

Post by sdan »

dmd wrote: post #7
sdan wrote: post #6

Love the implementation. Can't help but think about another "startup" or project that uses Machine Learning to predict your bash commands... which in most if not all cases is probably not necessary XD.

Like this? https://tabnine.com/blog/deep/

Yikes. Yes.

Not sure if other developers agree with me on this: I probably don't need autocompletion, I'm not writing an essay; I'm writing code where every character is a lot more impactful than forgetting a semicolon here or there. For this reason, having autocompletion could probably be an annoyance than helpful.

Re: How Bash Completion Works

#12

Post by nfoz »

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 command tab-completes and only "sees" the mp3, but I actually wanted to know that the .txt was there as well (and in some cases, open it with the media player!)

3. When the completion has a wrong view of the options provided by a program (e.g. completion is not aware of some useful options). Instead of looking at the man-page, I've been tricked by a bad completion-set.

I would love a better shell with good completion, but I need to avoid these types of problems. Does anyone else run into this?

Re: How Bash Completion Works

#13

Post by gpderetta »

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…

I've run into all of these, but, FWIW, I still prefer smart autocompletion in bash by a large margin. Somehow I learned to avoid the bad areas I guess.

Re: How Bash Completion Works

#14

Post by roryrjb »

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…

Some of this could be down to the completions that are provided. A package such as bash-completions comes with completions for a lot of common software. One specific solution to your problem, well a suggestion is to use oksh (https://github.com/ibara/oksh) a portable version of pdksh (public domain Korn shell) that comes from OpenBSD. The reason why I recommend this shell is that it has programmable completion, although it is much simpler than what's provided by bash and that aside from the built in file name completion it won't come with anything else and you won't find (aside from people's dotfiles on Github) any packages that provide you with anything. Basically you have to customise it to your needs, but because the completion is so simple, whenever you find yourself in a situation where you'd want completion, spend a few minutes adding it to your .kshrc and move on.

Re: How Bash Completion Works

#15

Post by roryrjb »

unixhero wrote: post #5
techntoke wrote: post #3

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

To be fair. Bash does not have a large footprint.

As an alternative, as mentioned already in response to another comment is oksh (https://github.com/ibara/oksh), a portable version of OpenBSD's pdksh. It's in the same Bourne shell lineage as bash but is lighter and the completion is simpler: you have to customise it if you want it to work for you, but it's very easy and quick to do.

Re: How Bash Completion Works

#16

Post by eurg »

mdaniel wrote: post #10

> `function _fizzbuzz () {` I find that extra keyword distracting, when [POSIX.2 doesn't require it][1] and some folks going so far as to say to [actively avoid it][2] Is there some good reason for it, or people are just used to a programming language requiring `fun` before a declaration, so it's programmer muscle memory? _1: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V... _2: http://mywiki.wooledge.o…

Simple keywords for definitions can make grepping for stuff much easier. Given that shell allows other forms, it isn't that helpful in practice. I still use it because my eyes find start-of-definition faster with common patterns that are not just special-chars. YMMV.

Edit: I usually don't care for portability, and just use bash. Shell is so ugly already, I refuse to write my personal stuff in portability hell mode. Rather level up my Civilization skills instead.

Re: How Bash Completion Works

#17

Post by hnlmorg »

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…

Coincidentally just this week I've working to resolve point 1 in my own shell (https://github.com/lmorg/murex). The compromise I came up with was:

- The shell would attempt to return all suggestions immediately

- However a subset of functions which are known to be slower queries (like recursive directory look ups on larger file system hierarchies) are given a "soft timeout" -- where after that timeout is reached, the slower faster subset of functions are returned as the suggestions while the slower subset continues to run in the background

- The slower subset are also given a "hard timeout" where when that point is reached, if the function still hasn't completed then it is just killed. Any results is has produced (if any) by that point are appended to the auto-completion suggestions.

- If the slower subset finished before the hard timeout then it is appended to the suggestions. If it finishes before the soft timeout then it's just part of the suggestions.

At the moment it's only been implemented for file and directory suggestions. The fast function is just any files and directories in the current directory level; where as the slow function will return a larger directory hierarchy (for quick navigating akin to fzf). But the plan is to extend it further to support other dynamic completers as well.

This wouldn't completely solve your point though. If the "fast" query actually runs slow (eg you're trying to complete when inside a network mounted filesystem when the network is dropping) then the shell would still hang. At some point I'll add timeouts on them as well. But I am inching towards that goal.

Be warned though, because this feature is less than a week old, it's still only in a feature branch. :)

Your point on 3 is apt too. One of the things I built early on was man page parsing for auto-completion suggestions. I've since learned that I'm not alone in that regard either (Fish does it as well -- and from some of the demo's I've watched it looks like they've done a nicer job there too).

More recently I've also been writing tools that parse binaries for flags as well (in instances where you download a statically compiled binary - eg terraform - and thus don't have any corresponding man pages). That work is very much in it's infancy though.

Re: How Bash Completion Works

#18

Post by hnlmorg »

sdan wrote: post #11
dmd wrote: post #7

Earlier quoted context omitted.

Like this? https://tabnine.com/blog/deep/

Yikes. Yes. Not sure if other developers agree with me on this: I probably don't need autocompletion, I'm not writing an essay; I'm writing code where every character is a lot more impactful than forgetting a semicolon here or there. For this reason, having autocompletion could probably be an annoyance than helpful.

Personally I'm the exact opposite - weirdly for the same reasons you cited too. When programming I can usually predict what will come next or the compiler will usually slap me if I've done something dumb. Whereas it's easier to miss something in a shell because everything is a little more "golfed" and mistakes can go unnoticed for a while if you're being down-right careless.

I'd love it if there was a way to do a "test run" of a command line where it prints what it would do without actually touching the file system (for example).

Re: How Bash Completion Works

#19

Post by sdan »

hnlmorg wrote: post #18
sdan wrote: post #11

Earlier quoted context omitted.

Yikes. Yes. Not sure if other developers agree with me on this: I probably don't need autocompletion, I'm not writing an essay; I'm writing code where every character is a lot more impactful than forgetting a semicolon here or there. For this reason, having autocompletion could probably be an annoyance than helpful.

Personally I'm the exact opposite - weirdly for the same reasons you cited too. When programming I can usually predict what will come next or the compiler will usually slap me if I've done something dumb. Whereas it's easier to miss something in a shell because everything is a little more "golfed" and mistakes can go unnoticed for a while if you're being down-right careless. I'd love it if there was a way to do a "te…

Pretty sure a simple "dry run" is what you're looking for. Not sure what programs support it, but I know Docker for one does.

Re: How Bash Completion Works

#20

Post by hnlmorg »

sdan wrote: post #19
hnlmorg wrote: post #18

Earlier quoted context omitted.

Personally I'm the exact opposite - weirdly for the same reasons you cited too. When programming I can usually predict what will come next or the compiler will usually slap me if I've done something dumb. Whereas it's easier to miss something in a shell because everything is a little more "golfed" and mistakes can go unnoticed for a while if you're being down-right careless. I'd love it if there was a way to do a "te…

Pretty sure a simple "dry run" is what you're looking for. Not sure what programs support it, but I know Docker for one does.

Sorry yes, "dry run".

There are definitely ways of doing it on a command by command basis but what I was more thinking about was a dry run on an entire pipeline. It's not a use case I tend to run into much these days though because there are usually better tools.

Post reply on HN