all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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.





  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.