Add a predicate for canonical file name

Add a predicate for canonical file name

[Tino Calancha]

Hi,

i dont see in Emacs a predicate for a file name being canonical.
We have a predicate for absolute file names, `file-name-absolute-p'.
In some cases we might want to check if the file name is canonical.
For instance, following might fail to set point in simple.el line:
it fails when `dired-goto-file' argument is not canonical:

(let* ((dir (expand-file-name "lisp" source-directory))
        (file (expand-file-name "simple.el" dir)))
   (when (file-name-absolute-p file)
     (dired-other-window dir)
     (goto-char (point-min))
     (dired-goto-file (abbreviate-file-name file))))
     ;; (dired-goto-file file))) ; This works.


Do you think has sense to add a predicate as follows?:
If the answer is yes: where should be defined?

(defsubst myfile-name-canonical-p (filename)
   "Return non-nil if FILENAME specifies an absolute canonical file name."
   (string= filename (expand-file-name filename)))

Following is a simple comparison `file-name-absolute-p' with
`myfile-name-canonical-p':

(let ((dirs '("./foo" "../foo" "/foo//bar" "/foo/./bar" "/foo/../bar" 
"~/bar"
               "//foo/bar" "/foo/bar" "/foo/bar/" 
"/sudo:baz@-pc:/foo/bar/")))
   (mapcar 'file-name-absolute-p dirs))
=> (nil nil t t t t t t t t)

(let ((dirs '("./foo" "../foo" "/foo//bar" "/foo/./bar" "/foo/../bar" 
"~/bar"
               "//foo/bar" "/foo/bar" "/foo/bar/" 
"/sudo:baz@-pc:/foo/bar/")))
   (mapcar 'myfile-name-canonical-p dirs))
=> (nil nil nil nil nil nil t t t t)

Re: Add a predicate for canonical file name

[Eli Zaretskii]

> From: Tino Calancha <tino.calancha@gmail.com>
> Date: Mon, 12 Sep 2016 17:23:03 +0900 (JST)
> Cc: tino.calancha@gmail.com
> 
> i dont see in Emacs a predicate for a file name being canonical.

Keeping in mind that just running a file name through expand-file-name
will guarantee an absolute (and "canonical") file name as result, what
problem would such a predicate solve that invoking expand-file-name
doesn't?  Especially given that your implementation calls
expand-file-name anyway?

> We have a predicate for absolute file names, `file-name-absolute-p'.

I personally never had a problem with the notion of "absolute file
name".  Yes, file names like "~/foo/bar" and "~user/foo" cause
file-name-absolute-p to return non-nil, but this is so obscure and
marginal feature that I doubt many Lisp programmers even remember
that.

> (defsubst myfile-name-canonical-p (filename)
>    "Return non-nil if FILENAME specifies an absolute canonical file name."
>    (string= filename (expand-file-name filename)))

Using string= here will cause false negatives, e.g. with Windows file
names that use backslashes vs forward slashes, or due to letter-case
differences on case-insensitive file systems.  Did you really mean
that?

But anyway, the need for this is not clear to me.

Thanks.

Re: Add a predicate for canonical file name

[Stefan Monnier]

> Using string= here will cause false negatives, e.g. with Windows file
> names that use backslashes vs forward slashes, or due to letter-case
> differences on case-insensitive file systems.  Did you really mean
> that?

Indeed, such notions have already been requested and discussed here, and
it's not clear exactly what is needed and when.

I can see several different meanings of "canonical", i.e. representative
member of an equivalence class (and I'd be inclined to prefer a function
that checks for "equivalence" between two file names rather than
a function that tries to find one canonical name).  The equivalence
classes could be:

- equivalent regardless of the actual on-disk data.  I.e. this can't
  take symlinks or hard links into account.  Questions remain about
  whether it could presume the "normal semantics of the most common
  file-system".  E.g. should it assume case-insensitive names in
  MacOS/Windows and case-sensitive in GNU/Linux?

- equivalent in practice for the current state of the file-system.
  You can test this equivalence by comparing the output of
  `file-attributes', except when the name corresponds to a file that
  doesn't exist (yet?).

Which flavor do you want?


        Stefan

Re: Add a predicate for canonical file name

[Philipp Stephani]

[-- Attachment #1: Type: text/plain, Size: 1945 bytes --]

Stefan Monnier <monnier@iro.umontreal.ca> schrieb am Mo., 12. Sep. 2016 um
22:09 Uhr:

> > Using string= here will cause false negatives, e.g. with Windows file
> > names that use backslashes vs forward slashes, or due to letter-case
> > differences on case-insensitive file systems.  Did you really mean
> > that?
>
> Indeed, such notions have already been requested and discussed here, and
> it's not clear exactly what is needed and when.
>
> I can see several different meanings of "canonical", i.e. representative
> member of an equivalence class (and I'd be inclined to prefer a function
> that checks for "equivalence" between two file names rather than
> a function that tries to find one canonical name).  The equivalence
> classes could be:
>
> - equivalent regardless of the actual on-disk data.  I.e. this can't
>   take symlinks or hard links into account.  Questions remain about
>   whether it could presume the "normal semantics of the most common
>   file-system".  E.g. should it assume case-insensitive names in
>   MacOS/Windows and case-sensitive in GNU/Linux?
>

You couldn't even do that because case-folding on Windows depends on the
file system. The only possibilities I see here are converting backslashes
into slashes (or vice versa), and collapsing "//" and "/./". You couldn't
even collapse "/../" because of symlinks. (Or you could ignore directory
symlinks, as in https://golang.org/pkg/path/#Clean).


>
> - equivalent in practice for the current state of the file-system.
>   You can test this equivalence by comparing the output of
>   `file-attributes', except when the name corresponds to a file that
>   doesn't exist (yet?).
>

Like all filesystem operations, this easily introduces race conditions if
decisions are made based on it: What might be an equivalent file name now
(pointing to the same inode), might not be a nanosecond later.
Over all, such an operation sounds more useful than it actually is.

[-- Attachment #2: Type: text/html, Size: 3050 bytes --]

Re: Add a predicate for canonical file name

[Stefan Monnier]

>> - equivalent regardless of the actual on-disk data.  I.e. this can't
>> take symlinks or hard links into account.  Questions remain about
>> whether it could presume the "normal semantics of the most common
>> file-system".  E.g. should it assume case-insensitive names in
>> MacOS/Windows and case-sensitive in GNU/Linux?
> You couldn't even do that because case-folding on Windows depends on the
> file system.

That's what I said: « Questions remain about whether it could presume the
"normal semantics of the most common file-system". »

Doesn't mean you can't do it.  Just that you may end up doing it in
a way which isn't what the caller expects/needs.

> You couldn't even collapse "/../" because of symlinks.

Here again, that's actually a choice.  `expand-file-name` (and by
extension, Emacs in general) already made the choice to disregard
this case.


        Stefan

Re: Add a predicate for canonical file name

[John Yates]

[-- Attachment #1: Type: text/plain, Size: 472 bytes --]

On Mon, Sep 12, 2016 at 4:01 PM, Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

> I can see several different meanings of "canonical", i.e. representative
> member of an equivalence class (and I'd be inclined to prefer a function
> that checks for "equivalence" between two file names rather than
> a function that tries to find one canonical name).


​A further wrinkle arises from Unicode normalization.  IIRC Linux uses NFC,
MacOS uses NFD.

/john​

[-- Attachment #2: Type: text/html, Size: 1348 bytes --]

Re: Add a predicate for canonical file name

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > ​A further wrinkle arises from Unicode normalization.  IIRC Linux uses NFC,
  > MacOS uses NFD.

Do you mean Linux, the kernel, or GNU/Linux, the operating system?
I would suppose that Linux has no reason to concern itself with this
question.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Add a predicate for canonical file name

[Kalle Olavi Niemitalo]

Richard Stallman <rms@gnu.org> writes:

>   > ​A further wrinkle arises from Unicode normalization.  IIRC Linux uses NFC,
>   > MacOS uses NFD.
>
> Do you mean Linux, the kernel, or GNU/Linux, the operating system?
> I would suppose that Linux has no reason to concern itself with this
> question.

Linux cares about it when reading file names from Apple's HFS+
file system.  I think the file names are stored as NFD on disk
and the hfsplus_readdir function converts them to NFC, except I'm
not sure the conversion entirely matches Unicode specifications.

Re: Add a predicate for canonical file name

[John Yates]

[-- Attachment #1: Type: text/plain, Size: 752 bytes --]

On Sat, Oct 15, 2016 at 7:07 PM, Kalle Olavi Niemitalo <kon@iki.fi> wrote:

> Richard Stallman <rms@gnu.org> writes:
>
> Linux cares about it when reading file names from Apple's HFS+
> file system.  I think the file names are stored as NFD on disk
> and the hfsplus_readdir function converts them to NFC, except I'm
> ​​
>
> not sure the conversion entirely matches Unicode specifications.
>

​I know that on Linux a readdir returns NFC strings.  Are you saying
that even though HFS+ stores NFD on MacOS it return NFC?  Or
are you saying that the Linux ​

​HFS+ driver performs a conversion?
If only the latter then my point that the definition of a canonical
filename​
is
​host OS
specific remains.

​/john​

[-- Attachment #2: Type: text/html, Size: 2323 bytes --]

Re: Add a predicate for canonical file name

[Kalle Olavi Niemitalo]

John Yates <john@yates-sheets.org> writes:

> Or are you saying that the Linux HFS+ driver performs a conversion?

Yes: in Linux 3.6.0, fs/hfsplus/dir.c (hfsplus_readdir) calls
fs/hfsplus/unicode.c (hfsplus_uni2asc), which first converts
decomposed UTF-16 to precomposed UTF-16 and then converts that to
the charset specified with the "nls" mount option.

Re: Add a predicate for canonical file name

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Linux cares about it when reading file names from Apple's HFS+
  > file system.

Oh, I see.  Thanks.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.