On Wed 17 Jun 2020 at 10:04:19 (+0200), Anders Andersson wrote: > On Tue, Jun 16, 2020 at 9:48 PM David Wright <deb...@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.