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: Thu, 28 Mar 2019 18:44:09 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Jordan Wilson <jordan.t.wilson@gmx.com> writes:

> Hi,

Hi Jordan,

sorry for the late reply; as usual it takes time for me to find an MS
Windows machine for test.

> this bug is similar to my previously reported bug #33791. I'm running
> Emacs 26.1 (with the patched files.el that fixed that bug[1]) on Windows
> 10. I've replicated this with "emacs -Q".
>
> When using eshell connected to a GNU/Linux machine, `eshell/cp' and
> `eshell/mv' (which are called in eshell with the commands "cp" and "mv")
> both return an "Invalid argument" error when the source and destination
> are relative paths on the remote machine.
>
> Recipe:
> - connect to GNU/Linux machine using plink:
>     /plink:jordan@domain.com:/home/jordan/
> - cp/mv a file between locations on the remote machine
>     /plink:jordan@domain.com:/home/jordan $ cp file.txt directory/
> - returns:
>    Opening output file: Invalid argument, 
> c:/plink:jordan@domain.com:/home/jordan/file.txt
>
> I'm guessing it's a problem of not correctly handling the relative TRAMP
> paths, as it works if provided the full paths for the source and
> destination.

I could reproduce the problem with "GNU Emacs 27.0.50 (build 1, 
x86_64-w64-mingw32)
 of 2019-01-17". It has nothing to do with eshell. My recipe:

--8<---------------cut here---------------start------------->8---
C-x C-f /plinkx:detlefx:/home/albinus/ ;; This is a remote GNU/Linux machine.

M-: (expand-file-name "123" "tmp/") ;; 123 is a file, tmp is a directory there.

=> "c:/plinkx:detlefx:/home/albinus/tmp/123"
--8<---------------cut here---------------end--------------->8---

I have added traces to this, with M-x trace-function-background for
expand-file-name, tramp-sh-handle-expand-file-name, and
tramp-file-name-handler. The latter function is Tramp's outmost
function. The traces look like this:

======================================================================
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"
======================================================================

Looks, like Tramp returns the proper value "/plinkx:detlefx:/home/albinus/tmp/",
and then in its way through expand-file-name the drive letter is
added. Since this is a C function, I'm not able to debug further.

Eli, could you pls check this?

> Thanks.

Best regards, Michael.





reply via email to

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