GNU bug report logs - #36502
27.0.50; infinite loop in file-name-case-insensitive-p

Previous Next

Full log

View this message in rfc822 format

From: Ken Brown <kbrown <at> cornell.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: "dan <at> dpsutton.com" <dan <at> dpsutton.com>, "schwab <at> suse.de" <schwab <at> suse.de>, "36502 <at> debbugs.gnu.org" <36502 <at> debbugs.gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>, "npostavs <at> gmail.com" <npostavs <at> gmail.com>
Subject: bug#36502: Fwd: bug#36502: 27.0.50; infinite loop in file-name-case-insensitive-p
Date: Wed, 10 Jul 2019 21:57:51 +0000

On 7/8/2019 1:23 PM, Eli Zaretskii wrote:
> LGTM, thanks.  Can we have a test for this subtle use case, so that we
> never regress?

I just found another case where expand-file-name can yield a non-absolute 
result.  Assuming there is no user "foo", we have

(let ((default-directory "~foo"))
   (expand-file-name "bar"))
=> "~foo/~foo/bar"

This is a ridiculous result, in addition to not being absolute.

Part of what's confusing here is that file-name-absolute-p returns t on file 
names starting with "~", even though its doc string explicitly states that such 
a file name is not absolute.

My inclination is that if default-directory starts with "~", then we should try 
to convert it to a (truly) absolute file name.  If this doesn't work, then we 
should forget the special interpretation of "~" and just treat default-directory 
the same as any other relative name.  This means we would get 
"<invocation-directory>/~foo" if invocation-directory is absolute, and "/~foo" 
otherwise.

Does this seem reasonable?  Or are there other suggestions?

Ken

Previous Next

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