From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/32873 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: 16 Oct 2000 16:39:25 -0400 Sender: owner-ding@hpc.uh.edu Message-ID: References: <200010161812.TAA25555@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 1035169082 22215 80.91.224.250 (21 Oct 2002 02:58:02 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 02:58:02 +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 1ACEAD051E for ; Mon, 16 Oct 2000 16:41:34 -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 PAB07299; Mon, 16 Oct 2000 15:41:16 -0500 (CDT) Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Mon, 16 Oct 2000 15:39:41 -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 PAA11678 for ; Mon, 16 Oct 2000 15:39:32 -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 539E1D051E for ; Mon, 16 Oct 2000 16:39:50 -0400 (EDT) Original-Received: (qmail 22969 invoked by uid 500); 16 Oct 2000 20:39:47 -0000 Mail-Followup-To: ding@gnus.org Original-To: ding@gnus.org In-Reply-To: Dave Love's message of "Mon, 16 Oct 2000 19:12:18 +0100" Original-Lines: 29 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:32873 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:32873 Dave Love writes: > I don't understand this. One of the points about expand-file-name is > that it gets to do magic depending on the file name. Right. Now suppose you have a file name that would invoke magic if expanded, but that you want to interpret literally - maybe it came from directory-files, for example - so it might contain arbitrary characters, but you know that it needs no massaging to become the name of an actual file. In that case, expand-file-name won't necessarily give you the file name you want. > PJ> I think file-name-as-directory and directory-file-name are > PJ> idempotent on all platforms, although they aren't documented as > PJ> such, AFAICT. > > I'm not sure why that's relevant, I'm not sure *that* it's relevant. I mentioned it only in passing. > but even if it's generally true in the absence of handlers -- I > don't know -- I don't think you can say what a random handler might > do, e.g. for remote files on an arbitrary system. expand-file-name, file-name-as-directory and directory-file-name are just string operations. Handlers aren't involved until I/O is attempted, AFAIK. paul