Re: bash-completion pros/cons
On Wed 17 Jun 2020 at 10:04:19 (+0200), Anders Andersson wrote:
> On Tue, Jun 16, 2020 at 9:48 PM David Wright <deblis@lionunicorn.co.uk> wrote:
> > Where bash-completion does get in the way for me is, for example,
> > where you download a file that's, say, a PDF but it arrives via wget
> > called, say, index_0001.3872359.html, for whatever reason.
> > So you type xpdf inde [TAB] and bash-completion refuses to
> > complete the name any further. If you're lucky, typing * [RETURN]
> > will work, if there aren't any disruptive filenames which match
> > inde*, but in other cases the fastest workaround I know is to type
> > [HOME]less[SPACE][END] whereupon bash-completion is happy to match
> > any old filename for the less command, which you then rub out.
> >
> > That's just one example, but it represents a whole class where it
> > seems that a bunch of files have disappeared because bash won't match them.
>
> First time this happened to me (it also happens with buggy
> completion-scripts where the author doesn't know all the ways to use
> the tool) I found that bash maps M-/ to "complete-filename" by
> default. This can be used in all contexts. The only problem is that I
> always forget the combo.
Thanks. This is part of man bash that I hadn't visited for too long.
It probably covers most cases, and I just used it to complete
xpdf index.html\?id=00000172-c4ea-d07a-a7f7-ccff84da0000
(which is a PDF of USA v John Bolton just downloaded from Politico).
The only snag (I think) is that, in the presence of a file called,
say, indolent-45.pdf, typing xpdf ind [TAB] will immediately
complete to xpdf indolent45.pdf without revealing that any other
ind* files exist (that aren't .pdf files themselves).
Not of great importance to me, because I normally rename files to
conform with conventions.
Cheers,
David.
Reply to: