bug#70792: 30.0.50; [PATCH] Add Eshell support for expanding absolute file names within the current remote connection

[Michael Albinus]

Jim Porter <jporterbugs@gmail.com> writes:

Hi Jim,

>> We could start with "/local::". I'm simply not so optimistic like
>> Jim,
>> that it will be easy. Likely, se need a full Tramp backend for this, say
>> tramp-local.el. The respective file name handler should remove the
>> "/local::" prefix from the arguments, call the original file operation,
>> and add the "/local::" prefix on the results where appropriate.
>> And somehow, I'd like to check that this is called from Eshell
>> only. Am
>> I paranoid? Will people use it on their own?
>
> Maybe the better solution would simply be for "/local:"[1] to be an
> Eshell-only syntax that DTRT within Eshell. There shouldn't be any
> conflict so long as Tramp promises not to add a "local" method. :)

Promised. Tramp uses just a tramp-file-name structure in tramp-null-hop,
that's it.

> Now, it's possible that this could conflict with Tramp's alternate
> file name syntax, but a) this feature will be disabled by default to
> avoid automatically changing the meaning of existing Eshell forms, and
> b) Eshell could look at Tramp's syntax and change the spelling for
> "/local:" to avoid collisions if we wanted to avoid this.

OK.

> (If in the future, we came up with an Emacs-wide use case for this, it
> should be possible to upgrade "/local:" to a full magic file name. I'm
> not sure why we'd want this though.)
>
> [1] Note the single colon, though I'm not dead-set on this. If it's
> just an Eshell notation and not part of Tramp, we don't necessarily
> need to follow Tramp syntax. Of course, if we wanted to keep open the
> possibility that this becomes a new Tramp method, maybe the "::" is
> the more forward-thinking route.

Anyway, even if you implement this completely in Eshell, I recommend to
write a file-name-handler for this. Potential 70+ primitive file
operations cannot be handled w/o such a basis, I fear.

Best regards, Michael.