[திங்கள் பிப்ரவரி 10, 2025] Michael Albinus wrote:
> Visuwesh <visuweshm@gmail.com> writes:
>
> Hi,
>
>> That reminds me why my :override advice was simpler. Indeed, I had to
>> get rid of that test to ensure that the function would work as intended
>> for remote shell buffers. It never made much sense IMO and I got the
>> impression that it is in place as a "let's be absolutely sure" measure.
>> I can say that I face no issues with the test omitted thus far. It could
>> be a product of me being in control of $PS1 for local and remote shells
>> though.
>
> Well. The host part of the URL could be anything, and must not be the
> same like the current host name. So perhaps the check could be like
> this, "to be absolutely sure":
>
> (when-let* ((url (url-generic-parse-url text))
> ((string= (url-type url) "file"))
> ((or (null (url-host url))
> ;; Use `downcase' to match `url-generic-parse-url' behavior
> (string= (url-host url)
> (downcase
> (or (file-remote-p default-directory 'host)
> (system-name)))))))
> (ignore-errors
> (cd-absolute
> (concat (file-remote-p default-directory)
> (url-unhex-string (url-filename url)))))))
>
> WDYT?
This unfortunately breaks down in my use case. In my .ssh/config I have
for a host:
Host remote-n2
User user
Hostname node2
ProxyJump remote
and when I create a remote shell buffer with
(shell "*remote*" "/ssh:user@remote-n2:~")
and say
remote-n2% cd ~/.ssh
remote-n2% pwd
/home/user/.ssh
evaluating
default-directory ;; => "/ssh:user@remote-n2:/home/user/"
shows instead. This is all because $HOSTNAME is not actually remote-n2
but "node2":
remote-n2% echo $HOSTNAME
node2
remote-n2% echo $PS1
\[\e]7;file://\H$PWD\e\\\]remote-n2%
Although I am not sure how common this type of scenario is where the
hostname as Tramp knows it and $HOSTNAME is mismatched.