On Thu, Jan 7, 2021 at 11:32 AM D. Hugh Redelmeier via talk <talk@gtalug.org> wrote:

| From: Dhaval Giani via talk <talk@gtalug.org>

| On Thu, Jan 7, 2021 at 10:58 AM D. Hugh Redelmeier via talk <talk@gtalug.org> wrote:

| > This fails: | > evince "RE: someting.pdf" | | Stupid question, does replacing " with ' help? IIRC ' does no | substitution at all. And it just feels like an escape issue. Does it | think RE is a protocol due to the ":" there. Maybe you can also try to | escape that ":" and see if it opens.

Good suggestion. No, using ' instead of " doesn't change what happens. So this is evince trying to handle RE: as magical.

Also: evince 'RE\: something.pdf' fails because evince tries to open a file with \ in its name.

That is because within the single quotes, it will not use the \ as an escape character. I'm unsure of the behaviour within double quotes. Dhaval

On Thu, Jan 7, 2021 at 12:04 PM D. Hugh Redelmeier via talk <talk@gtalug.org> wrote:

| From: Dhaval Giani via talk <talk@gtalug.org>

| On Thu, Jan 7, 2021 at 11:32 AM D. Hugh Redelmeier via talk <talk@gtalug.org> wrote:

| > Also: | > evince 'RE\: something.pdf' | > fails because evince tries to open a file with \ in its name. | | That is because within the single quotes, it will not use the \ as an | escape character. I'm unsure of the behaviour within double quotes.

OK, my model is that there are two entities that are doing quoting/globbing/etc.

1. the shell

2. the application program (evince) itself.

This second is un-UNIX-like behaviour. But common in other operating systems.

The single quotes are not seen by 2. They are interpreted by 1.

But I established that the RE: was being handled (mishandled) by 2.

So I wanted a "quote" function for 2. I tried \ but 2 did not treat it as a metacharacter.

There might be a quote function for 2 but I don't know it.

There are applications that make interpretations of filenames but this often creates problems.

OK, good point. Can you run a strace on evince and see how it is calling open on that file?

- if a filename looks like a flag argument, applications will try to handle it as a flag argument. Many applications provide a workaround this with a - flag argument which means "treat the rest of the arguments as filenames, even if they start with -"

- scp interprets hostname:filename as just that. This means that 'RE: something.pdf" will be a problem for scp. Solution: prepend with ./

I don't know what evince is trying to do.

Just out of curiosity. When you try to use shell autocomplete using the tab key, what does it autocomplete to? Dhaval

On Thu, Jan 07, 2021 at 08:18:34PM -0500, Aruna Hewapathirane via talk wrote:

Why not simply rename the file to something.pdf ?

I just tested and the command(s) below works: mv 'RE: something.pdf' something.pdf && evince something.pdf && mv something.pdf 'RE: something.pdf'

unless of course there is a real need to have it work using evince "RE: someting.pdf"?

: is special in filenames if it is before the first directory separator for many programs since it might be host:filepath evince for example allows ftp://host/file so it clearly cares about : in the filename before any slash. That's why using ./ in front works. Otherwise you have to escape the : with a \ or perhaps even two of them depending who strips it. -- Len Sorensen

| From: Lennart Sorensen via talk <talk@gtalug.org> | : is special in filenames if it is before the first directory separator | for many programs That's not UNIX, that's MS-DOS. In UNIX, special interpretation is done by the shell. | since it might be host:filepath The ssh family of commands introduced this, and for that it is documented in those commands. | evince for example allows ftp://host/file so it clearly cares about : | in the filename before any slash. Now that I look, it is partially documented in evince(1). It says that the operand is a filename. But in the description of a filename, it includes a remote filename. It doesn't say what that is, except to give an FTP example "ftp://adobe.com/sample.pdf". I infer: it can be a filename or a URL. It is assumed to be a URL if it starts with letters and then a colon. If something happens to be a filename that matches that pattern, tough luck. Since, in practice, URLs seem to always contain "/", and filenames do not, that would be a better way to distinguish them. | That's why using ./ in front works. Otherwise you have to escape the : | with a \ or perhaps even two of them depending who strips it. No, \ does not work for that purpose (my experiments are in this thread).

On Fri, Jan 08, 2021 at 11:55:38AM -0500, D. Hugh Redelmeier via talk wrote:

| From: Lennart Sorensen via talk <talk@gtalug.org>

| : is special in filenames if it is before the first directory separator | for many programs

That's not UNIX, that's MS-DOS.

I said for many programs, not for unix in general.

In UNIX, special interpretation is done by the shell.

| since it might be host:filepath

The ssh family of commands introduced this, and for that it is documented in those commands.

| evince for example allows ftp://host/file so it clearly cares about : | in the filename before any slash.

Now that I look, it is partially documented in evince(1).

It says that the operand is a filename. But in the description of a filename, it includes a remote filename. It doesn't say what that is, except to give an FTP example "ftp://adobe.com/sample.pdf".

Well it's man page is about typical for a gnu project. Almost useless. :) Unfortunately it doesn't have an info document and the online docs are not much better.

I infer: it can be a filename or a URL. It is assumed to be a URL if it starts with letters and then a colon. If something happens to be a filename that matches that pattern, tough luck.

Yeah that seems to be the state of it. No fall back to plain filename if it fails to be a known http or ftp protocol. Maybe they figure that since you can't use : in a filename on windows, no one would do it anywhere.

Since, in practice, URLs seem to always contain "/", and filenames do not, that would be a better way to distinguish them.

somewhere/myfile.txt sure looks like it has a / in it.

| That's why using ./ in front works. Otherwise you have to escape the : | with a \ or perhaps even two of them depending who strips it.

No, \ does not work for that purpose (my experiments are in this thread).

Maybe \\ so the shell can steal one and evince get the other? Hmm, nope tried and doesn't work. ./ on the other hand does seem to work. -- Len Sorensen

On Fri, Jan 08, 2021 at 04:10:46PM -0500, Aruna Hewapathirane via talk wrote:

I had no idea evince can ftp till just now either..

Apparently it uses gvfs for file access and gvfs supports various url formats, and also things like 'trash:///my_file.pdf' if you use the trashcan in gnome.

I just tried it and yes it works but I do not yet fully understand the reason why it does work? Further clarification would be most welcome ?

The / in ./ makes it obvious that it is not a url since you can't have a / in the protocol name. gvfs thinks 're' is a protocol and hence 're:' is using that protocol to refer to the rest of the filename.

Tried all possible escape sequence but zilch. No cigar :-( And this is a bug that was documented way back in 2015 https://bugzilla.redhat.com/show_bug.cgi?id=1248086

And years later they are still arguing about how gvfs should handle this. Apparently using a full path starting with / works fine, using ./ in front works file. You can do 'file:///path/to/re: file.pdf' as well, but that's no different than using '/path/to/re: file.pdf' I would definitely avoid : in my filenames just for compatibility in general. -- Len Sorensen

On Fri, Jan 08, 2021 at 12:01:26PM -0500, D. Hugh Redelmeier via talk wrote:

This file's name was given by a formal process. The file is one of hundreds that must survive decades. One doesn't willy-nilly rename things without inviting chaos.

But isn't it a problem to have a filename that is illegal on windows and mac os and probably many others? That seems to invite not surviving potentially into the future.

A tool should behave in the expected way. In this case, I have had to modify my expectation (and respect for) evince.

That's for sure. Badly documented and badly behaved. -- Len Sorensen