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. 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).
>
> 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]
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).
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.
Cheers,
David.
