all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Davis Herring" <herring@lanl.gov>
To: "Drew Adams" <drew.adams@oracle.com>
Cc: 'Eli Zaretskii' <eliz@gnu.org>, emacs-devel@gnu.org
Subject: RE: file-truename, convert-standard-filename
Date: Fri, 26 Feb 2010 10:33:52 -0800 (PST)	[thread overview]
Message-ID: <50159.130.55.132.103.1267209232.squirrel@webmail.lanl.gov> (raw)
In-Reply-To: <CBCE1B91725342F29EDB05C1E433A34C@us.oracle.com>

[I was reading this old thread and thought I might provide my own useful
summary.]

> OK. Then add "and you do not know whether the file named exists" to what I
> wrote. Again, that is the general case.

I think too much attention is being paid to the question of whether files
exist, which adds noise because so often we don't know (in advance)
whether a particular file exists.

The simple explanation is this: out of the set of all possible strings,
some of them are valid filenames on a given platform/filesystem.  On GNU,
the only character that cannot occur in a filename is NUL, which is so
rarely considered that we say that the two sets (strings and valid
filenames) are the same.  On Windows, several common characters are
invalid: ? and * for instance.  (This is justified by the different rules
about wildcards in the common Windows shells.)  So there, the sets differ
substantially.  On DOS, things get even worse, because there are peculiar
restrictions on the use of . in filenames.  (It's not prohibited, but you
can only use one per path component, and it can't be the first character,
etc.)

When the user asks to visit a file, or we get a filename from `ls' or
whatever other system source, the distinction between these two sets is
unimportant, because system tools will only generate filenames in the
valid set, and reporting to the user that their filename is invalid is
sufficient (as they can then choose another).

However, when Emacs (or any of its libraries or extensions) picks a
filename, there is no intelligence that can react to an error when the
filename is invalid.  So we must plan ahead and have a mapping from the
set of strings to the (system-dependent) set of valid names.  That mapping
is `convert-standard-filename', and it is therefore necessary precisely
whenever it is Emacs itself that is choosing (or constructing, like the
`concat' examples) a filename.

The set of valid filenames is closed under the common operations on them
(like `file-name-directory', `file-relative-name', `expand-file-name',
`file-truename').  So once all agents picking filenames have chosen valid
ones, no invalid names will ever be generated from them, so
`convert-standard-filename' is never needed again.  This is why so many of
its uses are on literal strings; literals are the commonest way for Emacs
to "pick" filenames, and after that point it's unneeded.

It is of course true that an existing file must have a valid name, and an
invalid filename cannot name an existing file (since it can't even name a
nonexistent file, as one might create with `write-region').  But note that
nowhere in this exposition (outside of the introductory paragraph and this
one) is any mention made of whether files exist or not.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.




  parent reply	other threads:[~2010-02-26 18:33 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-05 17:31 file-truename, convert-standard-filename Drew Adams
2010-02-05 18:15 ` Andreas Schwab
2010-02-05 18:33   ` Lennart Borgman
2010-02-05 19:45     ` Andreas Schwab
2010-02-05 19:49       ` Lennart Borgman
2010-02-05 20:14     ` Stefan Monnier
2010-02-05 20:18       ` Lennart Borgman
2010-02-06  1:10       ` Miles Bader
2010-02-05 23:51   ` Drew Adams
2010-02-05 19:04 ` Eli Zaretskii
2010-02-05 23:51   ` Drew Adams
2010-02-06  0:17     ` Lennart Borgman
2010-02-06  8:45       ` Eli Zaretskii
2010-02-06 16:55         ` Lennart Borgman
2010-02-06 19:12           ` Eli Zaretskii
2010-02-06 19:20             ` Lennart Borgman
2010-02-06  9:01     ` Eli Zaretskii
2010-02-06 15:33       ` Drew Adams
2010-02-06 19:33         ` Eli Zaretskii
2010-02-06 20:46           ` Drew Adams
2010-02-06 21:58             ` Eli Zaretskii
2010-02-06 23:12               ` Drew Adams
2010-02-07  4:01                 ` Eli Zaretskii
2010-02-08  1:38                 ` Stefan Monnier
2010-02-08  2:46                   ` Drew Adams
2010-02-26 18:33                 ` Davis Herring [this message]
2010-02-26 19:12                   ` Drew Adams
2010-02-26 19:35                     ` Davis Herring
2010-02-26 20:25                       ` Drew Adams
  -- strict thread matches above, loose matches on Subject: below --
2010-02-06  3:52 MON KEY
2010-02-06  8:28 ` Eli Zaretskii
     [not found]   ` <d2afcfda1002061814nc3e178fl5d93e21ea6bae7b5@mail.gmail.com>
2010-02-07  2:16     ` MON KEY
     [not found]     ` <83wrypelms.fsf@gnu.org>
2010-02-07 23:26       ` MON KEY
2010-02-08  0:28         ` Andreas Schwab
2010-02-08  4:10         ` Eli Zaretskii
     [not found]           ` <d2afcfda1002091330y53017b24w5e6bdf3c3d131a97@mail.gmail.com>
2010-02-09 21:32             ` MON KEY
2010-02-09 21:59               ` Andreas Schwab
2010-02-09 22:32             ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50159.130.55.132.103.1267209232.squirrel@webmail.lanl.gov \
    --to=herring@lanl.gov \
    --cc=drew.adams@oracle.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.