From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Peter Dyballa Newsgroups: gmane.emacs.help Subject: Re: Lisp code to expand /~ and // but not env vars? Date: Mon, 3 Oct 2005 12:50:03 +0200 Message-ID: <661026f5efbc685ec3b4d2684647bf71@Web.DE> References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1128345554 1979 80.91.229.2 (3 Oct 2005 13:19:14 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 3 Oct 2005 13:19:14 +0000 (UTC) Cc: Help-Gnu-Emacs Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Mon Oct 03 15:19:02 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EMQCz-0004is-Cu for geh-help-gnu-emacs@m.gmane.org; Mon, 03 Oct 2005 15:18:21 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EMQCy-0001Ap-7K for geh-help-gnu-emacs@m.gmane.org; Mon, 03 Oct 2005 09:18:20 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EMQBC-0000ro-96 for help-gnu-emacs@gnu.org; Mon, 03 Oct 2005 09:16:30 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EMQB6-0000oO-9b for help-gnu-emacs@gnu.org; Mon, 03 Oct 2005 09:16:25 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EMQB5-0000o6-WE for help-gnu-emacs@gnu.org; Mon, 03 Oct 2005 09:16:24 -0400 Original-Received: from [217.72.192.224] (helo=smtp06.web.de) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1EMQAo-0006GJ-UT for help-gnu-emacs@gnu.org; Mon, 03 Oct 2005 09:16:07 -0400 Original-Received: from [84.245.189.147] (helo=[192.168.1.2]) by smtp06.web.de with asmtp (TLSv1:RC4-SHA:128) (WEB.DE 4.105 #317) id 1EMQAl-0001Wt-00; Mon, 03 Oct 2005 15:16:03 +0200 In-Reply-To: X-Image-Url: http://homepage.mac.com/sparifankal/.cv/thumbs/me.thumbnail Original-To: "Drew Adams" X-Mailer: Apple Mail (2.623) X-Sender: Peter_Dyballa@web.de X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:29880 Archived-At: Am 03.10.2005 um 02:03 schrieb Drew Adams: > Function `expand-file-name' does not replace "//" and "/~" as > `substitute-in-file-name' does. > // is in UNIX nonsense. The root is / and does not get more root when written as '//' -- this only has in ancient (Apollo) Domain OS a meaning (Domain OS could create ad-hoc networks and // was the root of the individual members in the network). '//' is created as a text in mini-buffer when you either try to find a file or try to dired. The right means to handle such strings would be to substitute everything from the beginning to // with /. '/~' probably in every OS is nonsense. / is the root; ~ is, when followed by a /, my home directory; ~, when followed by a user's login name, means that user's home directory. The sequence '/~' happens to appear in mini-buffer when you either try to find a file or try to dired. The right means to handle such strings would be to substitute everything from the beginning to /~ with ~. The routines in dired or find-file that handle such 'input' handle it already right. -- Greetings Pete There's no sense in being precise when you don't even know what you're talking about. -- John von Neumann