Re: Using tramp with "RemoteCommand"

[Daniel Gomez]

Hi Michael,

thanks for the reply. Setting tramp-verbose to 10 helped me identify the 
issue, and it was clearly related to the prompt.
I got it to work without issues after I changed the argument to --pty 
from /usr/bin/zsh to /bin/sh.
I then noticed I had to play the rc trick on my zshrc to get it to work 
with zsh:

```
if [[ $TERM == "dumb" ]]; then
    unsetopt zle && PS1='> '
    return
fi
```

And now things work as expected.
I still have issues getting python to run, but I assume that is not 
directly related to TRAMP, but rather to my configuration.
I'll continue investigating and hopefully that too will work soon.

Kind regards,
Daniel

Am 28.03.2023 18:39 schrieb Michael Albinus:
> Daniel Gomez <d.gomez@posteo.org> writes:
>
> Hi Daniel,
>
> > I would like to tramp into a compute node of an HPC cluster.
> > That requires an ssh connection to a login node and then using `srun`
> > to request an interactive session.
> > If using a terminal, all I need is to set up the following on my
> > .ssh/config, and then `ssh computenode` gets me directly to the
> > compute node:
> >
> > ```
> > Host computenode
> >      User user
> >      HostName loginnode.edu
> >      IdentityFile ~/.ssh/id_loginnode
> >      RequestTTY yes
> >      RemoteCommand srun --partition=partition --account=account
> >      --gpus=1   --pty /usr/bin/zsh
> > ```
> >
> > However, when connecting via TRAMP this doesn't work, because
> > [apparently TRAMP cannot be used with "RemoteCommand".][1]
> >
> > **Question: How can I use TRAMP with RemoteCommand, or how can I have
> >   Tramp connect directly to an HPC compute node with `srun`?**
>
> I wouldn't say that Tramp doesn't work with RemoteCommand ever. But the
> command must open an interactive shell on the remote side; that's what
> Tramp expects.
>
> I don't know srun, but your example let me believe it opens a remote
> zsh. That would be OK.
>
> Please set tramp-verbose to 10, and rerun your test. It will produce a
> Tramp debug buffer, which we could analyze then.
>
> > Regards,
> > Daniel
>
> Best regards, Michael.