From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Davis Herring" Newsgroups: gmane.emacs.devel Subject: RE: file-truename, convert-standard-filename Date: Fri, 26 Feb 2010 10:33:52 -0800 (PST) Message-ID: <50159.130.55.132.103.1267209232.squirrel@webmail.lanl.gov> References: <83k4urfqs9.fsf@gnu.org> <0B5BFE3DC87648888328B75164292F06@us.oracle.com> <83bpg2g2l8.fsf@gnu.org> <834oluf9c8.fsf@gnu.org> <07544B532C8E490F96FE0B1CF403C510@us.oracle.com> <83zl3mdo22.fsf@gnu.org> Reply-To: herring@lanl.gov NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: dough.gmane.org 1267209275 1445 80.91.229.12 (26 Feb 2010 18:34:35 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 26 Feb 2010 18:34:35 +0000 (UTC) Cc: 'Eli Zaretskii' , emacs-devel@gnu.org To: "Drew Adams" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 26 19:34:30 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Nl51B-0001sY-Eg for ged-emacs-devel@m.gmane.org; Fri, 26 Feb 2010 19:34:29 +0100 Original-Received: from localhost ([127.0.0.1]:57080 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nl51A-0003CE-QJ for ged-emacs-devel@m.gmane.org; Fri, 26 Feb 2010 13:34:28 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nl50e-00039U-G0 for emacs-devel@gnu.org; Fri, 26 Feb 2010 13:33:56 -0500 Original-Received: from [140.186.70.92] (port=41731 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nl50d-00039L-LT for emacs-devel@gnu.org; Fri, 26 Feb 2010 13:33:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Nl50c-00077U-Pq for emacs-devel@gnu.org; Fri, 26 Feb 2010 13:33:55 -0500 Original-Received: from proofpoint2.lanl.gov ([204.121.3.26]:58285) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Nl50c-00077I-G7; Fri, 26 Feb 2010 13:33:54 -0500 Original-Received: from mailrelay2.lanl.gov (mailrelay2.lanl.gov [128.165.4.103]) by proofpoint2.lanl.gov (8.14.3/8.14.3) with ESMTP id o1QIXqcJ018519; Fri, 26 Feb 2010 11:33:52 -0700 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by mailrelay2.lanl.gov (Postfix) with ESMTP id 39D3515FC866; Fri, 26 Feb 2010 11:33:52 -0700 (MST) X-NIE-2-Virus-Scanner: amavisd-new at mailrelay2.lanl.gov Original-Received: from webmail1.lanl.gov (webmail1.lanl.gov [128.165.4.106]) by mailrelay2.lanl.gov (Postfix) with ESMTP id 1B54C15FC863; Fri, 26 Feb 2010 11:33:52 -0700 (MST) Original-Received: by webmail1.lanl.gov (Postfix, from userid 48) id 19336450001; Fri, 26 Feb 2010 11:33:52 -0700 (MST) Original-Received: from 130.55.132.103 (SquirrelMail authenticated user 196434) by webmail.lanl.gov with HTTP; Fri, 26 Feb 2010 10:33:52 -0800 (PST) In-Reply-To: User-Agent: SquirrelMail/1.4.8-5.7.lanl7 X-Priority: 3 (Normal) Importance: Normal X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-02-26_06:2010-02-06, 2010-02-26, 2010-02-25 signatures=0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:121404 Archived-At: [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.