From: Michael Albinus <michael.albinus@gmx.de>
To: Jordan Wilson <jordan.t.wilson@gmx.com>
Cc: 34834@debbugs.gnu.org
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 [thread overview]
Message-ID: <871s2qsxli.fsf@gmx.de> (raw)
In-Reply-To: <87o96f4v47.fsf@gmx.com> (Jordan Wilson's message of "Tue, 12 Mar 2019 21:54:00 +0000")
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.
next prev parent reply other threads:[~2019-03-28 17:44 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-12 21:54 bug#34834: 26.1; Remote `eshell/mv' and `eshell/cp' on Windows: Opening output file: Invalid argument, c:/home/ Jordan Wilson
2019-03-28 17:44 ` Michael Albinus [this message]
2019-03-28 17:52 ` Eli Zaretskii
2019-03-28 17:57 ` Michael Albinus
2019-03-28 19:29 ` Eli Zaretskii
2019-03-29 11:16 ` Michael Albinus
2019-03-29 12:37 ` Eli Zaretskii
2019-03-29 13:24 ` Michael Albinus
2019-03-29 14:12 ` Eli Zaretskii
2019-03-29 16:02 ` Michael Albinus
2019-03-29 17:46 ` Eli Zaretskii
2020-09-01 15:59 ` Eli Zaretskii
2020-09-05 11:31 ` Eli Zaretskii
2020-08-26 22:46 ` Paul Eggert
2020-08-27 13:28 ` Paul Eggert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871s2qsxli.fsf@gmx.de \
--to=michael.albinus@gmx.de \
--cc=34834@debbugs.gnu.org \
--cc=jordan.t.wilson@gmx.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.