What I want to have in shell (filename) completion

May 4, 2015

I've been using basic filename completion in my shell for a while now, and doing so has given me a perspective on what advanced features of this I'd find useful and which strike me as less useful. Unfortunately for me, the features that I'd find most useful are the ones that are the hardest to implement.

Put simply, the problem with basic filename completion is that any time you want to use even basic shell features like environment variables, you lose completion. Do you refer to some directories through convenience variables? Nope, not any more, because you can choose between completing a long name and not completing, say, '$ml/afilename'.

(I know, bash supports completing filenames that use environment variables. Probably zsh does as well. I'm not interested in switching to either right now.)

But environment variables are just one of the ways to shorten filenames. Two more cases are using wildcards to match unique or relatively unique subsets of a long filename and using various multi-match operators to specify several filenames in some directory or the like. Both of these would be handy to be able to do filename completion for. In fact, let's generalize that: what I'd really like is for my shell to be able to do filename completion in the face of any and all things that can appear in filenames and get expanded by the shell. Then I could combine the power of filename completion and the power of all of those handy shell operators together.

Of course this is easier said than done. I know that what I'm asking for is quite a challenging programming exercise and to some extent a design exercise once we get to the obscure features. But it sure would be handy (more handy, in my biased opinion, than a number of other completion features).

(I've never used eg bash's smart context aware autocompletion of program arguments in general, so I don't know for sure how useful I'd find it; however, my personal guess is 'not as much as full filename completion'. I'm so-so on autocompletion of program names; I suppose I do sometimes use programs with annoyingly long names, so my shell might as well support it. Again I'd rate it well below even autocompletion with environment variables, much less the full version.)


Comments on this page:

By jer at 2015-05-04 02:57:01:

Not sure I get your second point, but completion on variables just works in zsh and so does complicated matching based on some patterns, too. Maybe it actually is worth a try? Which shell are you currently using?

By dozzie at 2015-05-04 05:14:38:

@jer:

[...] so does complicated matching based on some patterns, too.

I believe it's not quite what cks meant. I think he wants the pattern (with glob characters) to stay unexpanded after hitting tab, and zsh expands the pattern to whatever matches -- multiple paths, that is.

I can't actually think of much that can appear in filenames and get expanded by the shell that zsh doesn't handle. What would you want in the case of a command substitution: it might not be ideal if the command gets run more than once. In many cases the tab key will do expansion directly and often that is more useful, especially if the expansion produces more than one word. It is common to have expansion only directly after the expandable term so in my configuration $ml<tab> will expand $ml while $ml/af<tab> will complete files inside the shortcut without expanding. It is possible to configure such details: very much so but it isn't always trivial. In the particular case of wanting completion rather than expansion after wildcards, you need to know to use _match instead of _expand; in my case that's bound to a different key.

In terms of completion of program arguments, zsh often has descriptions associated with the arguments which is really useful. Actually completing them is often less useful depending on the command.

The smarter completion is really useful either when completing things other than files or where it can reduce the number of matches for filename completion, e.g. after chmod, zsh will only complete files to which the permission change will have an effect.

By cks at 2015-05-04 11:19:26:

I use Byron Rakitzis's version of the Plan 9 rc shell. Rc is very different in syntax (and in some capabilities) than Bourne shells and changing would be relatively traumatic since I've been using rc for what is now a very long time.

In thinking about it, I think that I want shell globs to stay unexpanded at least when they expand to multiple things and perhaps all of the time. I'd have to use a shell that did this to be sure what was most useful. I know that immediately expanding to multiple files is wrong, because I may be intending to narrow or otherwise refine the completion and doing a multi-expansion immediately ruins that.

Written on 04 May 2015.
« Sometimes knowing causes does you no good (and sensible uses of time)
Monitoring tools should report timestamps (and what they're monitoring) »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon May 4 01:16:52 2015
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.