From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/32935 Path: main.gmane.org!not-for-mail From: prj@po.cwru.edu (Paul Jarc) Newsgroups: gmane.emacs.gnus.general Subject: Re: (concat "/dir/name/" "foo") --> (expand-file-name "foo" "/dir/name/") Date: 22 Oct 2000 14:10:36 -0400 Sender: owner-ding@hpc.uh.edu Message-ID: References: <200010161812.TAA25555@djlvig.dl.ac.uk> <200010181755.SAA08846@djlvig.dl.ac.uk> <200010221600.RAA25651@djlvig.dl.ac.uk> NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1035169134 22522 80.91.224.250 (21 Oct 2002 02:58:54 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 02:58:54 +0000 (UTC) Return-Path: Original-Received: from spinoza.math.uh.edu (spinoza.math.uh.edu [129.7.128.18]) by mailhost.sclp.com (Postfix) with ESMTP id 4C779D051F for ; Sun, 22 Oct 2000 14:15:07 -0400 (EDT) Original-Received: from sina.hpc.uh.edu (lists@Sina.HPC.UH.EDU [129.7.3.5]) by spinoza.math.uh.edu (8.9.1/8.9.1) with ESMTP id NAB20832; Sun, 22 Oct 2000 13:11:37 -0500 (CDT) Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Sun, 22 Oct 2000 13:10:46 -0500 (CDT) Original-Received: from mailhost.sclp.com (postfix@66-209.196.61.interliant.com [209.196.61.66] (may be forged)) by sina.hpc.uh.edu (8.9.3/8.9.3) with ESMTP id NAA09958 for ; Sun, 22 Oct 2000 13:10:33 -0500 (CDT) Original-Received: from multivac.student.cwru.edu (multivac.STUDENT.CWRU.Edu [129.22.239.69]) by mailhost.sclp.com (Postfix) with SMTP id C9DD2D051F for ; Sun, 22 Oct 2000 14:10:58 -0400 (EDT) Original-Received: (qmail 25313 invoked by uid 500); 22 Oct 2000 18:10:58 -0000 Mail-Followup-To: ding@gnus.org Original-To: ding@gnus.org In-Reply-To: Dave Love's message of "Sun, 22 Oct 2000 17:00:40 +0100" Original-Lines: 50 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:32935 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:32935 Dave Love writes: > PJ> In each particular case of deciding whether to use > PJ> expand-file-name, > > I don't think you should be making any such decision. Let me rephrase. Whether a filename is to be expanded should be a documented part of any interface that uses filenames. Expansion is generally useful for users, so it would be done for most or all user interfaces, but not necessarily for programmatic interfaces. (This has the cost that a user typically can't use a name like "foo/../bar" literally when foo is a symlink, but we can live with that.) Then programs have to be careful to avoid, e.g., passing an expanded (or not expanded) name to another interface that expects an unexpanded (or expanded) name. You want to avoid multiple expansions in general, since expansion need not be idempotent, and you want to avoid expanding a name which is known to be literal but which might invoke magic - e.g., it came from directory-files - because its expansion might be a different name, naming a different file. So take a name given by the user, expand it once, then keep that expanded name for future use, and for building other filenames. For example: (setq expanded-name (expand-file-name directory-name-from-user)) ; once (setq directory-name (file-name-as-directory expanded-name)) ; once (concat directory-name literal-relative-name) ; whenever Avoiding multiple expansions also helps with performance, regardless of the correctness problems that might occur. > If you think you should be able to suppress contraction of ../ for > some reason, make a bug report with enough justification. I'm not > convinced. ../ was perhaps a bad example. But I can't make a bug report, because I haven't audited all the code that uses expand-file-name to see where names might be expanded twice. It would be easier and faster for the various people who've written the code to audit it themselves, if they hadn't thought of this issue when they wrote it. Then they'll also be more aware of the potential problem when they write new code. > I doubt we've changed much significant in that area, but there is a > tarball of a more recent version of the Lisp manual somewhere on > alpha.gnu.org. Got it, thanks. Yes, I see that expand-file-name, directory-file-name, and file-name-as-directory are subject to handlers, so idempotency cannot be generally guaranteed. It should probably be a goal of any handler, though. paul