GNU bug report logs - #65685
29.1; Inconsistent behavior of quoted file name "/:~" across platforms

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 65685 in the body.
You can then email your comments to 65685 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.1; Inconsistent behavior of quoted file name "/:~" across platforms
Date: Fri, 1 Sep 2023 12:22:09 -0700

To see this in action, run 'emacs -Q "/:~"' on both GNU/Linux and 
MS-Windows.[1] On GNU/Linux, this opens a dired buffer for the user's 
home directory. On MS-Windows, it opens a buffer for a new file named tilde.

According to the Emacs manual:

> ‘/:’ can also prevent ‘~’ from being treated as a special character
> for a user’s home directory. For example, /:/tmp/~hack refers to a
> file whose name is ~hack in directory /tmp.
I'd interpret this to mean that the MS-Windows behavior is correct. 
However, the example doesn't specifically say what should happen when 
the tilde comes immediately after the "/:". On the very rare occasions 
you might need it, you can always spell "a file named tilde in the 
current directory" like "/:./~".

This is relevant to some future Eshell changes I'm considering[2], where 
(I think) I'd like "/:~" to mean "the user's local home directory, even 
when default-directory is remote". In light of that, my selfish 
preference is that we keep the GNU/Linux behavior and standardize it 
across all systems. However, we could standardize the MS-Windows 
behavior instead; I'd then just have to call out the different Eshell 
semantics in the Eshell manual.

[1] You can see this inconsistency with other commands too, like "M-x cd 
RET /:~ RET".

[2] https://lists.gnu.org/archive/html/emacs-devel/2023-08/msg01244.html

Message #8 received at 65685 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 65685 <at> debbugs.gnu.org
Subject: Re: bug#65685: 29.1; Inconsistent behavior of quoted file name
 "/:~" across platforms
Date: Tue, 03 Oct 2023 13:22:10 +0200

[Message part 1 (text/plain, inline)]

Jim Porter <jporterbugs <at> gmail.com> writes:

Hi Jim,

> To see this in action, run 'emacs -Q "/:~"' on both GNU/Linux and
> MS-Windows.[1] On GNU/Linux, this opens a dired buffer for the user's
> home directory. On MS-Windows, it opens a buffer for a new file named
> tilde.
>
> According to the Emacs manual:
>
>> ‘/:’ can also prevent ‘~’ from being treated as a special character
>> for a user’s home directory. For example, /:/tmp/~hack refers to a
>> file whose name is ~hack in directory /tmp.
> I'd interpret this to mean that the MS-Windows behavior is
> correct. However, the example doesn't specifically say what should
> happen when the tilde comes immediately after the "/:". On the very
> rare occasions you might need it, you can always spell "a file named
> tilde in the current directory" like "/:./~".
>
> This is relevant to some future Eshell changes I'm considering[2],
> where (I think) I'd like "/:~" to mean "the user's local home
> directory, even when default-directory is remote". In light of that,
> my selfish preference is that we keep the GNU/Linux behavior and
> standardize it across all systems. However, we could standardize the
> MS-Windows behavior instead; I'd then just have to call out the
> different Eshell semantics in the Eshell manual.
>
> [1] You can see this inconsistency with other commands too, like "M-x
> cd RET /:~ RET".
>
> [2] https://lists.gnu.org/archive/html/emacs-devel/2023-08/msg01244.html

I've played a little bit with file-name-non-special. The result is the
appended patch, which expands always "/:~"  to the local home
directory. Could you pls check whether it works for you?

Best regards, Michael.

[Message part 2 (text/x-patch, attachment)]

Message #11 received at 65685 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 65685 <at> debbugs.gnu.org
Subject: Re: bug#65685: 29.1; Inconsistent behavior of quoted file name "/:~"
 across platforms
Date: Mon, 9 Oct 2023 21:27:00 -0700

On 10/3/2023 4:22 AM, Michael Albinus wrote:
> I've played a little bit with file-name-non-special. The result is the
> appended patch, which expands always "/:~"  to the local home
> directory. Could you pls check whether it works for you?

Thanks for the patch. I tested this on GNU/Linux and MS-Windows, and it 
behaves as expected for local files, but Tramp filenames from MS-Windows 
to a remote GNU/Linux seem wrong (though they were wrong before this 
patch too).

Before the patch (on Emacs 29.1), if I open "/ssh:remote:/:~", then 
Emacs opens the file "/ssh:remote:/:/Users/Jim/AppData/Local/Temp/~".

After the patch, Emacs opens the file "/ssh:remote:/Users/Jim/Documents".

Based on the direction in your patch, I'd expect Emacs to open 
"/ssh:remote:/home/jim/".

(I imagine a similar issue could occur on a local GNU/Linux system, but 
going from a local MS-Windows to a remote GNU/Linux has the benefit that 
the two systems have obviously-different directory layouts.)

Message #14 received at 65685 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 65685 <at> debbugs.gnu.org
Subject: Re: bug#65685: 29.1; Inconsistent behavior of quoted file name
 "/:~" across platforms
Date: Fri, 13 Oct 2023 16:26:19 +0200

Jim Porter <jporterbugs <at> gmail.com> writes:

Hi Jim,

> Before the patch (on Emacs 29.1), if I open "/ssh:remote:/:~", then
> Emacs opens the file "/ssh:remote:/:/Users/Jim/AppData/Local/Temp/~".
>
> After the patch, Emacs opens the file "/ssh:remote:/Users/Jim/Documents".
>
> Based on the direction in your patch, I'd expect Emacs to open
> "/ssh:remote:/home/jim/".

This is a Tramp bug. I've fixed this in the emacs-29 branch, and merged
it to the master branch afterwards. The fix shall solve both scenarios,
with and without the patch I've posted earlier here.

Could you pls test, whether the patch behaves now as intended?

Best regards, Michael.

Message #17 received at 65685 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 65685 <at> debbugs.gnu.org
Subject: Re: bug#65685: 29.1; Inconsistent behavior of quoted file name "/:~"
 across platforms
Date: Fri, 13 Oct 2023 17:31:32 -0700

On 10/13/2023 7:26 AM, Michael Albinus wrote:
> This is a Tramp bug. I've fixed this in the emacs-29 branch, and merged
> it to the master branch afterwards. The fix shall solve both scenarios,
> with and without the patch I've posted earlier here.
> 
> Could you pls test, whether the patch behaves now as intended?

I think this works now, thanks. (Note that I just eval'ed the new 
version of 'tramp-sh-handle-expand-file-name' on MS-Windows to test 
things out, since I don't have a build environment set up on my 
MS-Windows system.)

So with the patch you merged to Tramp, plus your other one for 
"lisp/files.el", I think this is all working consistently now.

Message #20 received at 65685 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 65685 <at> debbugs.gnu.org, michael.albinus <at> gmx.de
Subject: Re: bug#65685: 29.1;
 Inconsistent behavior of quoted file name "/:~" across platforms
Date: Sat, 14 Oct 2023 10:42:25 +0300

> Cc: 65685 <at> debbugs.gnu.org
> Date: Fri, 13 Oct 2023 17:31:32 -0700
> From: Jim Porter <jporterbugs <at> gmail.com>
> 
> On 10/13/2023 7:26 AM, Michael Albinus wrote:
> > This is a Tramp bug. I've fixed this in the emacs-29 branch, and merged
> > it to the master branch afterwards. The fix shall solve both scenarios,
> > with and without the patch I've posted earlier here.
> > 
> > Could you pls test, whether the patch behaves now as intended?
> 
> I think this works now, thanks. (Note that I just eval'ed the new 
> version of 'tramp-sh-handle-expand-file-name' on MS-Windows to test 
> things out, since I don't have a build environment set up on my 
> MS-Windows system.)
> 
> So with the patch you merged to Tramp, plus your other one for 
> "lisp/files.el", I think this is all working consistently now.

The added test fails on MS-Windows:

  Test files-tests-file-name-non-special-expand-file-name-tilde condition:
      (ert-test-failed
       ((should
	 (equal
	  (expand-file-name nospecial)
	  (expand-file-name ...)))
	:form
	(equal "/:c:/Documents and Settings/Zaretzky/Local Settings/Temp/files-testsvIKNPk/files-testse2cUFY" "c:/Documents and Settings/Zaretzky/Local Settings/Temp/files-testsvIKNPk/files-testse2cUFY")
	:value nil :explanation
	(arrays-of-different-length 92 90 "/:c:/Documents and Settings/Zaretzky/Local Settings/Temp/files-testsvIKNPk/files-testse2cUFY" "c:/Documents and Settings/Zaretzky/Local Settings/Temp/files-testsvIKNPk/files-testse2cUFY" first-mismatch-at 0)))

I tried to understand the idea of the change, or even the actual root
cause of the problem, but couldn't find that in the discussion or the
code.  It doesn't help that file-name-non-special has no doc string
and no documentation I could find about what it's supposed to do.

Let's please discuss this now, because I tend just to revert the
change on the emacs-29 branch, as it's too late there for untested
ideas for obscure problems.

Message #25 received at 65685-done <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 65685-done <at> debbugs.gnu.org
Subject: Re: bug#65685: 29.1; Inconsistent behavior of quoted file name
 "/:~" across platforms
Date: Sat, 14 Oct 2023 09:42:00 +0200

Version: 29.2

Jim Porter <jporterbugs <at> gmail.com> writes:

Hi Jim,

> I think this works now, thanks. (Note that I just eval'ed the new
> version of 'tramp-sh-handle-expand-file-name' on MS-Windows to test
> things out, since I don't have a build environment set up on my
> MS-Windows system.)
>
> So with the patch you merged to Tramp, plus your other one for
> "lisp/files.el", I think this is all working consistently now.

Thanks for the feedback, I've pushed it to the repositories. Closing the bug.

Best regards, Michael.

Message #28 received at 65685 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Jim Porter <jporterbugs <at> gmail.com>, 65685 <at> debbugs.gnu.org
Subject: Re: bug#65685: 29.1; Inconsistent behavior of quoted file name
 "/:~" across platforms
Date: Sat, 14 Oct 2023 09:48:25 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

Hi Eli,

> The added test fails on MS-Windows:
>
>   Test files-tests-file-name-non-special-expand-file-name-tilde condition:
>       (ert-test-failed
>        ((should
> 	 (equal
> 	  (expand-file-name nospecial)
> 	  (expand-file-name ...)))
> 	:form
> 	(equal "/:c:/Documents and Settings/Zaretzky/Local Settings/Temp/files-testsvIKNPk/files-testse2cUFY" "c:/Documents and Settings/Zaretzky/Local Settings/Temp/files-testsvIKNPk/files-testse2cUFY")
> 	:value nil :explanation
> 	(arrays-of-different-length 92 90 "/:c:/Documents and Settings/Zaretzky/Local Settings/Temp/files-testsvIKNPk/files-testse2cUFY" "c:/Documents and Settings/Zaretzky/Local Settings/Temp/files-testsvIKNPk/files-testse2cUFY" first-mismatch-at 0)))
>
> I tried to understand the idea of the change, or even the actual root
> cause of the problem, but couldn't find that in the discussion or the
> code.  It doesn't help that file-name-non-special has no doc string
> and no documentation I could find about what it's supposed to do.
>
> Let's please discuss this now, because I tend just to revert the
> change on the emacs-29 branch, as it's too late there for untested
> ideas for obscure problems.

Please give me a day to check the situation on MS Windows. I don't
believe the change would hurt Emacs 29 in any way, handling "/:~"
doesn't happen in real life I believe. It is just a preparation for a
planned change in Eshell.

I know, "Famous last words" and alike ...

Best regards, Michael.

Message #31 received at 65685 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Jim Porter <jporterbugs <at> gmail.com>, 65685 <at> debbugs.gnu.org
Subject: Re: bug#65685: 29.1; Inconsistent behavior of quoted file name
 "/:~" across platforms
Date: Sat, 14 Oct 2023 12:56:07 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

Hi Eli,

>> So with the patch you merged to Tramp, plus your other one for
>> "lisp/files.el", I think this is all working consistently now.
>
> The added test fails on MS-Windows:
>
>   Test files-tests-file-name-non-special-expand-file-name-tilde condition:
>       (ert-test-failed
>        ((should
> 	 (equal
> 	  (expand-file-name nospecial)
> 	  (expand-file-name ...)))
> 	:form
> 	(equal "/:c:/Documents and Settings/Zaretzky/Local Settings/Temp/files-testsvIKNPk/files-testse2cUFY" "c:/Documents and Settings/Zaretzky/Local Settings/Temp/files-testsvIKNPk/files-testse2cUFY")
> 	:value nil :explanation
> 	(arrays-of-different-length 92 90 "/:c:/Documents and Settings/Zaretzky/Local Settings/Temp/files-testsvIKNPk/files-testse2cUFY" "c:/Documents and Settings/Zaretzky/Local Settings/Temp/files-testsvIKNPk/files-testse2cUFY" first-mismatch-at 0)))
>
> I tried to understand the idea of the change, or even the actual root
> cause of the problem, but couldn't find that in the discussion or the
> code.  It doesn't help that file-name-non-special has no doc string
> and no documentation I could find about what it's supposed to do.
>
> Let's please discuss this now, because I tend just to revert the
> change on the emacs-29 branch, as it's too late there for untested
> ideas for obscure problems.

I cannot reproduce the problem. My environment:

- MS Windows 10 VM
- MSYS2 MinGW 64-bit
- A fresh git checkout of the master branch, at commit
  548bc3e3d18ea6776032ca83dafbc89e3ddb5a5a
- Emacs recompiled, it reports "GNU Emacs 30.0.50 (build 13,
  x86_64-w64-mingw32) of 2023-10-14"
- Running "$ make -C test files-tests" yields

--8<---------------cut here---------------start------------->8---
Ran 113 tests, 111 results as expected, 0 unexpected, 2 skipped (2023-10-14 12:49:06+0200, 7.219525 sec)

2 skipped results:
  SKIPPED  files-tests-file-name-non-special--subprocess
  SKIPPED  files-tests-file-name-non-special-dired-compress-handler
--8<---------------cut here---------------end--------------->8---

What is the difference to your setup?

Best regards, Michael.

Message #34 received at 65685 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: jporterbugs <at> gmail.com, 65685 <at> debbugs.gnu.org
Subject: Re: bug#65685: 29.1; Inconsistent behavior of quoted file name
 "/:~" across platforms
Date: Sat, 14 Oct 2023 14:25:10 +0300

> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: Jim Porter <jporterbugs <at> gmail.com>,  65685 <at> debbugs.gnu.org
> Date: Sat, 14 Oct 2023 12:56:07 +0200
> 
> I cannot reproduce the problem. My environment:
> 
> - MS Windows 10 VM
> - MSYS2 MinGW 64-bit
> - A fresh git checkout of the master branch, at commit
>   548bc3e3d18ea6776032ca83dafbc89e3ddb5a5a
> - Emacs recompiled, it reports "GNU Emacs 30.0.50 (build 13,
>   x86_64-w64-mingw32) of 2023-10-14"
> - Running "$ make -C test files-tests" yields

It's Windows XP here, but I doubt that's the problem.  The test fails
for me both on master and on the emacs-29 branch, but the latter is my
worry, since I intend to start the pretest of Emacs 29.2 very soon.

> --8<---------------cut here---------------start------------->8---
> Ran 113 tests, 111 results as expected, 0 unexpected, 2 skipped (2023-10-14 12:49:06+0200, 7.219525 sec)
> 
> 2 skipped results:
>   SKIPPED  files-tests-file-name-non-special--subprocess
>   SKIPPED  files-tests-file-name-non-special-dired-compress-handler
> --8<---------------cut here---------------end--------------->8---
> 
> What is the difference to your setup?

I do

   $ cd test
   $ make lisp/files-tests

and get this:

  Ran 112 tests, 109 results as expected, 1 unexpected, 2 skipped (2023-10-14 14:18:07+0300, 9.375000 sec)

  1 unexpected results:
     FAILED  files-tests-file-name-non-special-expand-file-name-tilde

  2 skipped results:
    SKIPPED  files-tests-file-name-non-special--subprocess
    SKIPPED  files-tests-file-name-non-special-dired-compress-handler

The only difference I could think of is that the directory Emacs uses
here has whitespace in its name (see my original report), whereas on
Windows 10 it probably doesn't.

Message #37 received at 65685 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: jporterbugs <at> gmail.com, 65685 <at> debbugs.gnu.org
Subject: Re: bug#65685: 29.1; Inconsistent behavior of quoted file name
 "/:~" across platforms
Date: Sat, 14 Oct 2023 16:29:46 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

Hi Eli,

> The only difference I could think of is that the directory Emacs uses
> here has whitespace in its name (see my original report), whereas on
> Windows 10 it probably doesn't.

FTR, if I use a directory with spaces in its name, it fails for me as
well. I'm now debugging ...

Best regards, Michael.

Message #40 received at 65685 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: jporterbugs <at> gmail.com, 65685 <at> debbugs.gnu.org
Subject: Re: bug#65685: 29.1; Inconsistent behavior of quoted file name
 "/:~" across platforms
Date: Sat, 14 Oct 2023 18:48:16 +0200

[Message part 1 (text/plain, inline)]

Michael Albinus <michael.albinus <at> gmx.de> writes:

Hi Eli,

>> The only difference I could think of is that the directory Emacs uses
>> here has whitespace in its name (see my original report), whereas on
>> Windows 10 it probably doesn't.
>
> FTR, if I use a directory with spaces in its name, it fails for me as
> well. I'm now debugging ...

It looks, like it is a problem in the test case code
itself. abbreviate-file-name does not work as I expect in this
combination.

Well, since it isn't needed for the test, the appended patch has fixed
it for me. Would you like to check?

Best regards, Michael.

[Message part 2 (text/x-patch, attachment)]

Message #43 received at 65685 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: jporterbugs <at> gmail.com, 65685 <at> debbugs.gnu.org
Subject: Re: bug#65685: 29.1; Inconsistent behavior of quoted file name
 "/:~" across platforms
Date: Sat, 14 Oct 2023 22:07:41 +0300

> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: jporterbugs <at> gmail.com,  65685 <at> debbugs.gnu.org
> Date: Sat, 14 Oct 2023 18:48:16 +0200
> 
> >> The only difference I could think of is that the directory Emacs uses
> >> here has whitespace in its name (see my original report), whereas on
> >> Windows 10 it probably doesn't.
> >
> > FTR, if I use a directory with spaces in its name, it fails for me as
> > well. I'm now debugging ...
> 
> It looks, like it is a problem in the test case code
> itself. abbreviate-file-name does not work as I expect in this
> combination.

Can you tell more about this?  I'm surprised any file-related
primitive in Emacs cares about whitespace in file names.

> Well, since it isn't needed for the test, the appended patch has fixed
> it for me. Would you like to check?

I'd like to better understand the issue first.

Message #46 received at 65685 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: jporterbugs <at> gmail.com, 65685 <at> debbugs.gnu.org
Subject: Re: bug#65685: 29.1; Inconsistent behavior of quoted file name
 "/:~" across platforms
Date: Sun, 15 Oct 2023 09:11:19 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

Hi Eli,

>> >> The only difference I could think of is that the directory Emacs uses
>> >> here has whitespace in its name (see my original report), whereas on
>> >> Windows 10 it probably doesn't.
>> >
>> > FTR, if I use a directory with spaces in its name, it fails for me as
>> > well. I'm now debugging ...
>>
>> It looks, like it is a problem in the test case code
>> itself. abbreviate-file-name does not work as I expect in this
>> combination.
>
> Can you tell more about this?  I'm surprised any file-related
> primitive in Emacs cares about whitespace in file names.

Perhaps we have uncovered a bug in abbreviate-file-name, don't
know. I'll check when time permits.

However, it isn't related to the change in question of this bug report,
handling expand-file-name for constructs like "/:~..." and
"/ssh:host:/:~...".  abbreviate-file-name has been used to create a
temporary test file for this case, it isn't target of the test itself.

Best regards, Michael.

Message #49 received at 65685 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: jporterbugs <at> gmail.com, 65685 <at> debbugs.gnu.org
Subject: Re: bug#65685: 29.1; Inconsistent behavior of quoted file name
 "/:~" across platforms
Date: Sun, 15 Oct 2023 12:36:00 +0300

> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: jporterbugs <at> gmail.com,  65685 <at> debbugs.gnu.org
> Date: Sun, 15 Oct 2023 09:11:19 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> Hi Eli,
> 
> >> >> The only difference I could think of is that the directory Emacs uses
> >> >> here has whitespace in its name (see my original report), whereas on
> >> >> Windows 10 it probably doesn't.
> >> >
> >> > FTR, if I use a directory with spaces in its name, it fails for me as
> >> > well. I'm now debugging ...
> >>
> >> It looks, like it is a problem in the test case code
> >> itself. abbreviate-file-name does not work as I expect in this
> >> combination.
> >
> > Can you tell more about this?  I'm surprised any file-related
> > primitive in Emacs cares about whitespace in file names.
> 
> Perhaps we have uncovered a bug in abbreviate-file-name, don't
> know. I'll check when time permits.

I'd like to understand this sooner rather than latter.  Can you show
some simple recipe which fails under these conditions?

> However, it isn't related to the change in question of this bug report,
> handling expand-file-name for constructs like "/:~..." and
> "/ssh:host:/:~...".  abbreviate-file-name has been used to create a
> temporary test file for this case, it isn't target of the test itself.

I applied your changes to the test, and it passes after that, thanks.

Message #52 received at 65685 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: jporterbugs <at> gmail.com, 65685 <at> debbugs.gnu.org
Subject: Re: bug#65685: 29.1; Inconsistent behavior of quoted file name
 "/:~" across platforms
Date: Sun, 15 Oct 2023 11:50:38 +0200

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

Hi Eli,

>> >> >> The only difference I could think of is that the directory Emacs uses
>> >> >> here has whitespace in its name (see my original report), whereas on
>> >> >> Windows 10 it probably doesn't.
>> >> >
>> >> > FTR, if I use a directory with spaces in its name, it fails for me as
>> >> > well. I'm now debugging ...
>> >>
>> >> It looks, like it is a problem in the test case code
>> >> itself. abbreviate-file-name does not work as I expect in this
>> >> combination.
>> >
>> > Can you tell more about this?  I'm surprised any file-related
>> > primitive in Emacs cares about whitespace in file names.
>>
>> Perhaps we have uncovered a bug in abbreviate-file-name, don't
>> know. I'll check when time permits.
>
> I'd like to understand this sooner rather than latter.  Can you show
> some simple recipe which fails under these conditions?

I haven't completed all tests yet, still in debugging. As recent
result, I believe abbreviate-file-name works correctly.

Rather, the problem seems to be with temporary-file-directory. It is
used in the prelude of the test to set the HOME environment
variable. But later on, in the macros files-tests--with-temp-non-special
and files-tests--with-temp-non-special-and-file-name-handler, it is
modified to (file-truename temporary-file-directory) - this difference
seems to be the culprit.

>> However, it isn't related to the change in question of this bug report,
>> handling expand-file-name for constructs like "/:~..." and
>> "/ssh:host:/:~...".  abbreviate-file-name has been used to create a
>> temporary test file for this case, it isn't target of the test itself.
>
> I applied your changes to the test, and it passes after that, thanks.

Could you pls apply the appended patch instead? I'll continue to finish
all my tests, but if this patch passes also in your environment, it
would give me sufficient confidence that it is fixed.

Best regards, Michael.

[Message part 2 (text/x-patch, attachment)]

Message #55 received at 65685 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: jporterbugs <at> gmail.com, 65685 <at> debbugs.gnu.org
Subject: Re: bug#65685: 29.1; Inconsistent behavior of quoted file name
 "/:~" across platforms
Date: Sun, 15 Oct 2023 12:58:19 +0300

> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: jporterbugs <at> gmail.com,  65685 <at> debbugs.gnu.org
> Date: Sun, 15 Oct 2023 11:50:38 +0200
> 
> > I applied your changes to the test, and it passes after that, thanks.
> 
> Could you pls apply the appended patch instead? I'll continue to finish
> all my tests, but if this patch passes also in your environment, it
> would give me sufficient confidence that it is fixed.

After these changes, the tests also pass.

Message #58 received at 65685-done <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: jporterbugs <at> gmail.com, 65685-done <at> debbugs.gnu.org
Subject: Re: bug#65685: 29.1; Inconsistent behavior of quoted file name
 "/:~" across platforms
Date: Sun, 15 Oct 2023 12:29:12 +0200

Version: 29.2

Eli Zaretskii <eliz <at> gnu.org> writes:

Hi Eli,

>> Could you pls apply the appended patch instead? I'll continue to finish
>> all my tests, but if this patch passes also in your environment, it
>> would give me sufficient confidence that it is fixed.
>
> After these changes, the tests also pass.

Thanks. Pushed to the emacs-29 branch. Closing the bug.

Best regards, Michael.

Message #61 received at 65685 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: Jim Porter <jporterbugs <at> gmail.com>, 65685 <at> debbugs.gnu.org
Subject: bug#65685: 29.1; Inconsistent behavior of quoted file name "/:~"
 across platforms
Date: Sun, 15 Oct 2023 22:12:27 +0200

After the change, files-tests fail. 

Test files-tests-file-name-non-special-expand-file-name-tilde backtrace:
  signal(ert-test-failed (((should (equal (expand-file-name nospecial)
  ert-fail(((should (equal (expand-file-name nospecial) (expand-file-n
  (if (unwind-protect (setq value-354 (apply fn-352 args-353)) (setq f
  (let (form-description-356) (if (unwind-protect (setq value-354 (app
  (let ((value-354 'ert-form-evaluation-aborted-355)) (let (form-descr
  (let* ((fn-352 #'equal) (args-353 (condition-case err (let ((signal-
  (progn (let (file-name-handler-alist) (setq nospecial (file-name-quo
  (unwind-protect (progn (let (file-name-handler-alist) (setq nospecia
  (let* ((temporary-file-directory (file-truename temporary-file-direc
  (let ((process-environment (cons (format "HOME=%s" temporary-file-di
  (closure (t) nil (let ((process-environment (cons (format "HOME=%s" 
  ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
  ert-run-test(#s(ert-test :name files-tests-file-name-non-special-exp
  ert-run-or-rerun-test(#s(ert--stats :selector ... :tests ... :test-m
  ert-run-tests((not (or (tag :unstable) (tag :nativecomp))) #f(compil
  ert-run-tests-batch((not (or (tag :unstable) (tag :nativecomp))))
  ert-run-tests-batch-and-exit((not (or (tag :unstable) (tag :nativeco
  eval((ert-run-tests-batch-and-exit '(not (or (tag :unstable) (tag :n
  command-line-1(("-L" ":../../emacs/test" "-l" "ert" "-l" "lisp/files
  command-line()
  normal-top-level()
Test files-tests-file-name-non-special-expand-file-name-tilde condition:
    (ert-test-failed
     ((should (equal (expand-file-name nospecial) (expand-file-name ...)))
      :form
      (equal
       "/:/private/var/folders/qy/zstv16390nlcs47kz8nff_mm0000gn/T/files-testsgcrggv/files-testsHn7mpT"
       "/private/var/folders/qy/zstv16390nlcs47kz8nff_mm0000gn/T/files-testsgcrggv/files-testsHn7mpT")
      :value nil :explanation
      (arrays-of-different-length 94 92
				  "/:/private/var/folders/qy/zstv16390nlcs47kz8nff_mm0000gn/T/files-testsgcrggv/files-testsHn7mpT"
				  "/private/var/folders/qy/zstv16390nlcs47kz8nff_mm0000gn/T/files-testsgcrggv/files-testsHn7mpT"
				  first-mismatch-at 1)))
   FAILED   45/113  files-tests-file-name-non-special-expand-file-name-tilde (0.000818 sec) at ../../emacs/test/lisp/files-tests.el:686

Message #64 received at 65685 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: Jim Porter <jporterbugs <at> gmail.com>, 65685 <at> debbugs.gnu.org
Subject: Re: bug#65685: 29.1; Inconsistent behavior of quoted file name
 "/:~" across platforms
Date: Mon, 16 Oct 2023 09:07:23 +0200

Mattias Engdegård <mattias.engdegard <at> gmail.com> writes:

Hi Mattias,

> After the change, files-tests fail.
>
>    FAILED   45/113  files-tests-file-name-non-special-expand-file-name-tilde (0.000818 sec) at ../../emacs/test/lisp/files-tests.el:686

This is the master branch, isn't it? The emacs-29 branch has 112 test
cases only.

Eli did report this problem already, and I've fixed it in the emacs-29
branch with commit 07c45f20fd3, yesterday.

I've now merged the emacs-29 branch into master. Could you, pls, retest
with a fresh checkout?

Thanks, and best regards, Michael.

Message #67 received at 65685 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: Jim Porter <jporterbugs <at> gmail.com>, 65685 <at> debbugs.gnu.org
Subject: Re: bug#65685: 29.1; Inconsistent behavior of quoted file name "/:~"
 across platforms
Date: Mon, 16 Oct 2023 09:30:38 +0200

16 okt. 2023 kl. 09.07 skrev Michael Albinus <michael.albinus <at> gmx.de>:

> I've now merged the emacs-29 branch into master. Could you, pls, retest
> with a fresh checkout?

Now it works on master, too. Thank you so much, and sorry about my initial lack of patience.

Previous Next

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