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 <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).
>> 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.
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? 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?
>
> 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.
>
Attachment:
signature.asc
Description: OpenPGP digital signature