GNU bug report logs - #7617
24.0.50; `expand-file-name': removal of slashes

Previous Next

Full log

View this message in rfc822 format

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Eli Zaretskii'" <eliz <at> gnu.org>
Cc: 7617 <at> debbugs.gnu.org
Subject: bug#7617: 24.0.50; `expand-file-name': removal of slashes
Date: Mon, 13 Dec 2010 06:51:39 -0800

> > Besides a workable but ugly replace-regexp-in-string hack that saves
> > and restores consecutive slashes around a call to
> > `expand-file-name', I don't see a good way to do that.
> 
> If you seek suggestions for how to solve your problem in a non-ugly
> way, please tell more about the problem.  It's clear that one
> _solution_ to that problem is to have the old behavior of
> expand-file-name.  But that behavior is gone and will not come back.
> To suggest other solutions, we need to understand the problem.

The behavior is no longer provided by `expand*'.
But that behavior is what I want to achieve, in Lisp.
Achieving that behavior is the problem.
I understand that `expand*' is no longer the solution.

> > And we should say what the function
> > does/returns otherwise (e.g., say that it is undefined - i.e., that
> > it is defined only in the case where the args are acceptable names
> > for the file system).  If we tell users that the args must be of a
> > form acceptable by the current file system, then we should also tell
> > them what happens otherwise (raise an error?...).
> 
> If the argument doesn't have a valid file-name semantics, all bets are
> off.

Then that's what we should tell users: If either arg is not a file name
acceptable to the file system then the behavior is undefined (aka we have no
idea what will happen).  This is not obvious - since we demand valid file names
and produce a canonical name, one might well wonder what happens otherwise,
whether we raise an error, for example.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.