bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#34834: 26.1; Remote `eshell/mv' and `eshell/cp' on Windows: Opening


From: Michael Albinus
Subject: bug#34834: 26.1; Remote `eshell/mv' and `eshell/cp' on Windows: Opening output file: Invalid argument, c:/home/ ...
Date: Fri, 29 Mar 2019 12:16:17 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

>> Remote file names shouldn't get a drive letter. But this happened:
>
> Can you describe how this is supposed to work?  AFAIR, Tramp's
> file-name handler gets called, and then turns around and calls back
> into expand-file-name after inhibiting file-name handlers?  Or
> something like that.

I have an idea what happened. See the traces I gave in my first answer:

======================================================================
1 -> (expand-file-name "123" "tmp/")
| 2 -> (tramp-file-name-handler expand-file-name "tmp/" 
"/plinkx:detlefx:/home/albinus/")
| | 3 -> (tramp-sh-handle-expand-file-name "tmp/" 
"/plinkx:detlefx:/home/albinus/")
| | | 4 -> (tramp-file-name-handler file-name-as-directory 
"/plinkx:detlefx:/home/albinus/")
| | | 4 <- tramp-file-name-handler: "/plinkx:detlefx:/home/albinus/"
| | | 4 -> (expand-file-name "/home/albinus/tmp/")
| | | 4 <- expand-file-name: "c:/home/albinus/tmp/"
| | 3 <- tramp-sh-handle-expand-file-name: "/plinkx:detlefx:/home/albinus/tmp/"
| 2 <- tramp-file-name-handler: "/plinkx:detlefx:/home/albinus/tmp/"
1 <- expand-file-name: "c:/plinkx:detlefx:/home/albinus/tmp/123"
======================================================================

The buffer's default-directory is remote, "/plinkx:detlefx:/home/albinus/".
expand-file-name is called

--8<---------------cut here---------------start------------->8---
(expand-file-name "123" "tmp/")
--8<---------------cut here---------------end--------------->8---

This is entry "1" in the trace output. In function Fexpand_file_name,
line 794 of fileio.c, there is the check

--8<---------------cut here---------------start------------->8---
  handler = Ffind_file_name_handler (name, Qexpand_file_name);
--8<---------------cut here---------------end--------------->8---

This returns Qnil, because name is "123". Then we have in line 823

--8<---------------cut here---------------start------------->8---
  handler = Ffind_file_name_handler (default_directory, Qexpand_file_name);
--8<---------------cut here---------------end--------------->8---

This returns Qnil again, because default_directory is "tmp/". That's all
about checking for a file name handler. Later on, line 872, there is

--8<---------------cut here---------------start------------->8---
        default_directory = Fexpand_file_name (default_directory, Qnil);
--8<---------------cut here---------------end--------------->8---

which belongs to entry "2" of the traces above. It returns the proper
answer "/plinkx:detlefx:/home/albinus/tmp/". But this is too late; it
must happen before the second call of Ffind_file_name_handler.
Fexpand_file_name continues to work, it constructs the final answer
"/plinkx:detlefx:/home/albinus/tmp/123" *plus* the drive letter (I
suppose line 1047),

As you know, I cannot test it myself any fix, because I cannot build
Emacs for Windows.

> Meanwhile, the same problem happens in Emacs 26, so this is not new.

Yes. It is not so common to use a relative dir argument for
expand-file-name, and in the non-Windows case it works properly. So it
was uncovered for years.

Best regards, Michael.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]