Re: Happy with remote-shell $0, and its PATH

[Michael Albinus]

積丹尼 Dan Jacobson  writes:

Hi Dan,

> (info "(tramp) Android shell setup") says
>
>• ‘sh’ must be specified for remote shell since Android devices do
>  not provide ‘/bin/sh’.  ‘sh’ will then invoke whatever shell is
>  installed on the device with this setting:
>
>   (add-to-list 'tramp-connection-properties
>(list (regexp-quote "192.168.0.26") "remote-shell" "sh"))
>
> I have an idea,
> because we are already talking to the shell,
> can't we just tell it somehow to use "$0"?!

We must ensure a bourne-ish shell is called. $0 can be anything, we have
no control over this. That's why we don't recommend to use it, anywhere.

> Furthermore, at
>
>• TRAMP requires preserving ‘PATH’ environment variable from user
>  settings.  Android devices prefer ‘/system/xbin’ path over
>  ‘/system/bin’.  Both of these are set as follows:
>
>   (add-to-list 'tramp-remote-path 'tramp-own-remote-path)
>   (add-to-list 'tramp-remote-path "/system/xbin")
>
> what if we are happy with the path the remote ssh provides us,
> and don't want to change it? I.e., tramp should just use the ls, cp, rm,
> etc. that it finds on the path already in the ssh shell... so do mention
> how to enforce that.

If you are happy with the path on Android, you don't need to change it
as recommended. I have just documented what it takes for me to setup
an Android environment. Granted, I'm not an expert in this.

But I don't like to expect too much being set implicitly. That changes
often, from Android release to Android release, my experience says.

Best regards, Michael.

Re: No longer accessible host paths

[Michael Albinus]

JD Smith  writes:

Hi,

[pls keep tramp-devel@gnu.org in Cc. I'd appreciate comments also from
other users]

>> Well, I'm still playing with scenarios. For the time being, I have
>> called the function `tramp-rename-all-buffer-files' (but I'm not fixed
>> on this name). The idea is to rename a prefix by another prefix for
>> buffer-file-name in all related buffers, and let the user confirm that
>> choice for every matching buffer. The interactive case would be
>> 
>> M-x tramp-rename-all-buffer-files
>> Enter old Tramp connection: /method:badhost:
>> Enter new Tramp connection: /method:newhost:
>
> You could consider prompting with the longest prefix common to all
> files being visited on badhost.

But badhost is just a guess, based on a possible current-buffer with a
remote default-directory. If the current-buffer isn't remote, the
initial value must be chosen from the different remote connections which
exist. There can be several ones.

And if it is the wrong guess, you need to edit the proposed initial
value. So you would also need to remove the "longest prefix", which is
unpleasant.

Maybe the selection for the old connection could be performed in several
steps, including the longest prefix:

M-x tramp-rename-all-buffer-files
Enter old Tramp connection: /method:badhost:

This connection is proposed, based on current-buffer and/or available
remote connections. You can edit this, or type TAB. TAB results in path
completion, like

Enter old Tramp connection: /method:badhost:/longest/prefix/common/to/all/files

Of course, the implementation for the completion of the longest prefix
must be written newly as well, because the existing completion functions
won't work (badhost is not reachable anymore).

>> Then, Tramp would go through all buffers finding related ones
>> (buffer-file-name must start with "/method:badhost:"). For every such a
>> buffer, it asks interactively
>> 
>> Write file: /method:newhost:/path/to/file
>> 
>> given, that buffer has as buffer-file-name
>> "/method:badhost:/path/to/file". The user can edit the filename, and
>> write to another "/path/to/anotherfile" on newhost, or even change the
>> remote part. Or the user confirms.
>> 
>> Whewther "/method:badhost:" or "/method:newhost:" contains multi-hops,
>> doesn't matter.
>> 
>> We could even take the upper parts of the localname into account:
>> 
>> M-x tramp-rename-all-buffer-files
>> Enter old Tramp connection: /method:badhost:/path/to
>> Enter new Tramp connection: /method:newhost:/somewhere/else
>
> This is I think a good interface, especially when you start with the
> longest prefix common to all files with the same host-path.

Yep.

>> The file "/method:badhost:/path/to/file" would be written to
>> "/method:newhost:/somewhere/else/file" (still editable).
>> 
>> And finally, the target must not be a remote file name:
>> 
>> M-x tramp-rename-all-buffer-files
>> Enter old Tramp connection: /method:badhost:/path/to
>> Enter new Tramp connection: /somewhere/else
>
> I think it would be more targeted and easier for the user to
> understand if it’s a `tramp-rename-host-files` or so.  I.e. it renames
> only those tramp buffers visiting the same hostpath.  Then the
> function can prompt with the host path + shortest common prefix
> (e.g. /method:badhosts:/shortest/local/prefix), and allow the user to
> change it (e.g., to /method:hophost|method:newhost:/newpath/prefix).

`tramp-rename-host-files' does not fit. The remote part distinguishes
not only by host names, but also method and user names. What about
`tramp-rename-remote-files'?

>> would write "/method:badhost:/path/to/file" to "/somewhere/else/file".
>> 
>> After handling all such buffers, the command would cleanup the
>> connection to "/method:badhost:".
>> 
>> Something like this …
>
> Sounds like a great start, thanks for throwing some energy at it so quickly.  

Well, I have the feeling for a while that we need this kind of
functionality. Your message was the final kick for me to work on it.

> JD

Best regards, Michael.

Re: No longer accessible host paths

[JD Smith]

> On Nov 4, 2019, at 3:34 AM, Michael Albinus  wrote:
> 
> JD Smith mailto:jdtsm...@gmail.com>> writes:
> 
> Hi,
> 
> [pls keep tramp-devel@gnu.org  in Cc. I'd 
> appreciate comments also from
> other users]
> 
>>> Well, I'm still playing with scenarios. For the time being, I have
>>> called the function `tramp-rename-all-buffer-files' (but I'm not fixed
>>> on this name). The idea is to rename a prefix by another prefix for
>>> buffer-file-name in all related buffers, and let the user confirm that
>>> choice for every matching buffer. The interactive case would be
>>> 
>>> M-x tramp-rename-all-buffer-files
>>> Enter old Tramp connection: /method:badhost:
>>> Enter new Tramp connection: /method:newhost:
>> 
>> You could consider prompting with the longest prefix common to all
>> files being visited on badhost.
> 
> But badhost is just a guess, based on a possible current-buffer with a
> remote default-directory. If the current-buffer isn't remote, the
> initial value must be chosen from the different remote connections which
> exist. There can be several ones.

I was imagining running the command in a non-tramp buffer would result in an 
error.  

> And if it is the wrong guess, you need to edit the proposed initial
> value. So you would also need to remove the "longest prefix", which is
> unpleasant.

But now that I think of it, if you are visiting files at 10 different hosts, 
and *all* now need to be redirected through a new hop (for example), you might 
in fact prefer to rename all at once.  

> Maybe the selection for the old connection could be performed in several
> steps, including the longest prefix:
> 
> M-x tramp-rename-all-buffer-files
> Enter old Tramp connection: /method:badhost:
> 
> This connection is proposed, based on current-buffer and/or available
> remote connections. You can edit this, or type TAB. TAB results in path
> completion, like
> 
> Enter old Tramp connection: 
> /method:badhost:/longest/prefix/common/to/all/files
> 
> Of course, the implementation for the completion of the longest prefix
> must be written newly as well, because the existing completion functions
> won't work (badhost is not reachable anymore).

This is really important.  Ido and other aggressive completion tools seem to be 
good at hanging tramp when a host is no longer reachable. Since presumably the 
new command will be used when the host is no longer contactable, completion 
that visits the bad host has to be avoided. Of course, completion of the new 
host would work fine (assuming it’s valid). 

>>> Then, Tramp would go through all buffers finding related ones
>>> (buffer-file-name must start with "/method:badhost:"). For every such a
>>> buffer, it asks interactively
>>> 
>>> Write file: /method:newhost:/path/to/file
>>> 
>>> given, that buffer has as buffer-file-name
>>> "/method:badhost:/path/to/file". The user can edit the filename, and
>>> write to another "/path/to/anotherfile" on newhost, or even change the
>>> remote part. Or the user confirms.
>>> 
>>> Whewther "/method:badhost:" or "/method:newhost:" contains multi-hops,
>>> doesn't matter.
>>> 
>>> We could even take the upper parts of the localname into account:
>>> 
>>> M-x tramp-rename-all-buffer-files
>>> Enter old Tramp connection: /method:badhost:/path/to
>>> Enter new Tramp connection: /method:newhost:/somewhere/else
>> 
>> This is I think a good interface, especially when you start with the
>> longest prefix common to all files with the same host-path.
> 
> Yep.
> 
>>> The file "/method:badhost:/path/to/file" would be written to
>>> "/method:newhost:/somewhere/else/file" (still editable).
>>> 
>>> And finally, the target must not be a remote file name:
>>> 
>>> M-x tramp-rename-all-buffer-files
>>> Enter old Tramp connection: /method:badhost:/path/to
>>> Enter new Tramp connection: /somewhere/else
>> 
>> I think it would be more targeted and easier for the user to
>> understand if it’s a `tramp-rename-host-files` or so.  I.e. it renames
>> only those tramp buffers visiting the same hostpath.  Then the
>> function can prompt with the host path + shortest common prefix
>> (e.g. /method:badhosts:/shortest/local/prefix), and allow the user to
>> change it (e.g., to /method:hophost|method:newhost:/newpath/prefix).
> 
> `tramp-rename-host-files' does not fit. The remote part distinguishes
> not only by host names, but also method and user names. What about
> `tramp-rename-remote-files'?

That’s good.  Though maybe confusing if people imagine it would rename the file 
locally on disk?  Perhaps `tramp-edit-host-filepaths`?  

That name also gives me the idea for an alternative interface (picking up on 
your multiple steps approach):

Find all unique `/method1:host|method2:hop1…` values across all tramp buffers
`tramp-edit-host-files` would invoke a two stage input:
Prompt 1: Choose host to edit (empty for all hosts, use completion with unique 
list from #1)
Prompt 2: /method:host|method2:hop1…:/longest/prefix/path.

Re: No longer accessible host paths

[yary]

I often have similar scenario of editing via TRAMP and then switching
networks, without those issues. I don't use ido, and I do have auto-save to
local /tmp for all my tramp buffers, setting "Auto Save File Name
Transforms" regexp - see
https://www.gnu.org/software/emacs/manual/html_node/tramp/Auto_002dsave-and-Backup.html

Re: No longer accessible host paths

[Michael Albinus]

yary  writes:

Hi yari,

> I often have similar scenario of editing via TRAMP and then switching
> networks, without those issues. I don't use ido, and I do have
> auto-save to local /tmp for all my tramp buffers, setting "Auto Save
> File Name Transforms" regexp - see
> https://www.gnu.org/software/emacs/manual/html_node/tramp/Auto_002dsave-and-Backup.html

Yes, that works. But the case in question here is a different
one. Assume, you have a host (the same host) reachable under different
names and IP addresses, depending in which network you are located. At
work, you are in the company network. At home, you access via VPN.

You want to continue your work on the same file, whereever you
are. After you gave moved your laptop to the other network, you must
tell Tramp the new name of the remote machine. Existing buffers shall be
preserved, and updated accordingly.

Best regards, Michael.