On Thu 18 Jun 2020 at 22:31:31 (+0100), Darac Marjal wrote: > On 18/06/2020 21:14, David Wright wrote: > > On Thu 18 Jun 2020 at 20:38:15 (+0100), Darac Marjal wrote: > >> On 18/06/2020 20:15, David Wright wrote: > >>> 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.
1) This is what you have missed: the refusal to type any more. > >>>>> 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. 2) This is the partial fix: it cures the refusal to complete any further. > >>> 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). > >> While magic numbers exist (that is, specific bytes or sequences within a > >> file which identify the format of a file), > > Sure, file can identify it correctly, and mc can open it, regardless > > of the name. > > > >> opening every file which > >> matches "ind*", and filtering for just those which are PDFs, DVIs or > >> whatever other digital paper formats xpdf takes time. It's a *lot* > >> easier to simply replace ind* with ind*.pdf and discover that there's > >> only one match. > > That's not my point. I don't want to replace ind* with ind*.pdf. > > I want to do this: > > > > Google: 1:20-cv-01580-rcl document 3 > > > > Find the hit: > > > > www.politico.com › ... PDF > > UNITED STATES DISTRICT COURT FOR THE ... - Politico > > > > Right click, pick up the address and paste it into a commandline: > > > > $ wg-in-quotes > > 'https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&cad=rja&uact=8&ved=2ahUKEwizrb7b_YvqAhULWK0KHepjBGUQFjAKegQIBRAB&url=https%3A%2F%2Fwww.politico.com%2Ff%2F%3Fid%3D00000172-c4ea-d07a-a7f7-ccff84da0000&usg=AOvVaw3EhH0zUoJJ_RtEEsUbWKB3' > > > > […] > > > > index.html?id=00000172-c 100%[==================================>] > > 249.59K --.-KB/s in 0.1s > > > > 2020-06-18 13:22:52 (1.78 MB/s) - > > ‘index.html?id=00000172-c4ea-d07a-a7f7-ccff84da0000’ saved [255585/255585] > > > > And now I want to type > > > > $ xpdf ind [TAB] > > OK. Perhaps I didn't make myself clear. At this point, all bash knows is > that you're wanting to provide xpdf with an argument starting with > "ind". You agree that xpdf can't open just any file? The file types that > XPDF can handle are encoded in the bash completion function. Imagine you > have index.html, india.pdf, indulgent.mp3 and indolent.midi; which of > those do you want xpdf to open when you type "xpdf ind[tab]"? The PDF, > obviously. Agreed, that is what bash-completion is for (and a lot more, of course). > However, you have a file with an extension of > "html?id=00000172-c4ea-d07a-a7f7-ccff84da0000". How is any sort of > completion function supposed to recognise that as being something which > xpdf can read? It isn't. That's fine. > Well, what I was trying to imply is that the only way a > function can discover that is to open each matching file, analyse the > contents and filter them. Or, in other words, when you press the tab > key, it needs to run something like "file ind*|awk -F: '/PDF document/ > {print $1}'". Can you not see that this is extraordinarily more effort > than "ls ind*.pdf", and will only cause even more user complaints? We aren't discussing that, because that's ultra vires for bash-completion. > > in order to execute > > > > $ xpdf index.html\?id=00000172-c4ea-d07a-a7f7-ccff84da0000 > > > > and check it's the correct document. (With hits like this, the target > > file sometimes turns out to be a miserable little bit of HTML code.) > > > >> Arguably, another alternative would be to store the mime type of every > >> file as metadata associated with the file, but A) there are plenty of > >> file types which don't have mime types (e.g. applications, libraries and > >> many proprietary data formats would just be application/octet-stream) > >> and B) the "file extension" convention is cross-platform, portable and > >> has existed, virtually unchanged, for nearly half a century. > >>> 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). 3) And this is the snag. Rather than refusing to complete on anything, it completely completes the one name it recognises. That's what it's meant to do. There's no way it can know what the user knows, or suspects. For me, the benefits outweigh the disadvantages. The M-/ reminder was useful for me … > > Notice that I wrote ".pdf files" (name), not "PDF files" (contents). > > The bash-completion process works at a textual level; the contents of > > the file are irrelevant. And it all has to work even if you don't have > > the necessary permissions to open the file. > > > >>> Not of great importance to me, because I normally rename files to > >>> conform with conventions. … because refusals are relatively common, and unexpected completions of conventional file extensions are rare (for me). Cheers, David.
