When I log into a remote server, I don't get my aliases, etc (~/.bashrc). Even though I have Bash on that server.

Could it be because of this check:

Are there other ways to check if I'm "running interactively"?

Yes, it's probably due to the check against $PS1.

Perhaps try the solution from this StackOverflow post? https://unix.stackexchange.com/questions/259858/can-bash-tell-an-interactive-ssh-session-from-an-in-line-ssh-session

tl;dr, something like:

[ tty >/dev/null ] && return

Nope :-(

# If not running interactively, don't do anything
#[ -z "$PS1" ] && return
echo before
[ tty >/dev/null ] && return
echo after

$source ~/.bashrc
before

@mityukov I'm sweeping through this discussion to see what all is till not working. Is this fixed for you?

@fishcharlie moved it so we could leverage GitHub discussion's ability to reply directly to a specific comment. We still have regular GitHub issues open for SSH but those point out specific bugs and don't necesarilly communicate whether our SSH support is in a usable (reliable) state (it's not).

I'll send out updates here!

@fishcharlie moved it so we could leverage GitHub discussion's ability to reply directly to a specific comment. We still have regular GitHub issues open for SSH but those point out specific bugs and don't necesarilly communicate whether our SSH support is in a usable (reliable) state (it's not).

How involved is getting shell-parity for ZSH in SSH? Assuming it's not possible to open that up to outside contributors? :)

@zheng was working on that last week. I think we have a working build coming this wednesday right? @zheng

yes, that's correct

Made an issue for this: #1203

+1 to this issue. Same issue on Amazon Linux 2 instances.

From @mquinnv
so this same problem has basically made it so i can't use warp. i too had fish as my remote shell, but changing it to /bin/sh yields the same problem. changing my mac shell to /bin/zsh results in the same thing.

From @mquinnv
this is happening on Monterey as well.

from @platy
I've also got this, in my case I'm trying to ssh to a host which only has sh, it looks like warp can only ssh to hosts with bash. I get:

ash: syntax error: unexpected "("
Connection to localhost closed.

From the verbose output, I think the key is:

debug1: Sending command: exec -a bash bash --rcfile <(echo 'unset PS1; unset PS2; set -o vi; set +o vi; HISTCONTROL=ignorespace; printf '\\''\\u1b\\u50\\u24\\u64{"hook": "InitShell", "value": {"shell": "bash"}}\\u9c'\\''')

From @NikosEfthias
For now, I found a workaround.
If you connect to your server from tmux within warp everything works fine.

This also happens for zsh

from @serasset
I confirm that this happens each time an error message is broadcasted while no command is executed. This happens for instance if there is a broadcast message from the host.

This issue has been fixed

It still persist for me with stable_05

From @tekumara
On macOS I'm getting:

ssh remote
...
bash: warning: setlocale: LC_ALL: cannot change locale (en_AU.UTF-8)

This helps

LC_ALL=C.UTF-8 ssh remote

this is a bug, right? I did not get this on Terminal app

Hey @richardpringle is your zsh version 5.0.8 or older? If so, this is a known issue and a fix should be coming out in the next few weeks.

Yeah, I'm running 5.0.2. It's not my remote server though and I don't have perms to update.

@richardpringle this issue should be fixed in the latest version of warp!

confirmed!

Hi @kris-Nabis, you should check out the Honor PS1 setting. We don't honor PS1 by default, but we give you the option to opt-in!

Thanks for the quick response, but that is something I've already enabled:

Ah got it. I found the bug on our side. We'll fix this!

This should be resolved!

To answer your questions:

1. The warptmp folder is a folder where we create our own (theoretically temporary) set of rcfiles for zsh to bootstrap the shell to support Warp's block features; these rcfiles eventually load the user's rcfiles (effectively acting as a sort of pre-init script). This directory should get deleted as part of our bootstrapping; that doesn't seem to be working in your case. Flagging to @zheng who has looked into this some.
2. We don't currently provide a way to pass through any fancy typeahead performed by the shell (such as the completions you're mentioning). We have a completions library covering a variety of common commands/tools, but systemctl doesn't seem to be in there yet. I believe we will eventually support community contributions to that library (to increase coverage and help ensure things stay up-to-date), but unfortunately I don't have a good answer for you on this one at the moment. :(

Hey @bloveless, thanks for the report! We have an SSH wrapper that sets up the necessary environment for us to be able to provide features like blocks, and it currently doesn't play nicely with tmux. As a workaround, try disabling the use of the SSH wrapper (there's a toggle in Settings -> Features); I expect this will fix your issue.

We definitely want this to be a more seamless integration though - it's on our radar. :)

Thanks for telling me about that setting. I found it on my own shortly after I posted this and it did fix ssh for me. That’s awesome to hear that it’s on your radar!

Might want to add remote tmux sessions as unsupported on the SSH Wiki. Extremely popular pattern to not lose work, and it didn't occur to me that it wouldn't be supported. :)

Added your suggestion to our docs!

Same issue, lots of friction without path completion

I found that my ls has been aliased to ls --color=tty, when I unalias ls, it works

The above problem has been resolved, but I notice that if I Command-K while SSH'ed in to a remote host, the terminal session becomes unresponsive to any input. I end up issuing killall ssh in another local terminal session in order to get back control of the Warp tab.

@amadeusuzx Is this still happening to you? If so could you open an SSH Issue using this template?
https://github.com/warpdotdev/Warp/issues/new?assignees=&labels=&template=03_ssh.yml

Yes! Can you open a new issue using this template: https://github.com/warpdotdev/Warp/issues/new?assignees=&labels=&template=03_ssh.yml

OK thanks. I have another question. When I try SSH'ing to the VPS, warp doesn't show the login message, is that a feature or bug?

Normally it is shown as below:

This is a bug

Is this still a bug? Not seeing the login messages with warp

Still a bug!

Ok, so a fun hack:
1 ) SSH into server
2) nano ~/.bash_profile
3) add run-parts /etc/update-motd.d/ save.
4) Exit ssh and relogin. May or may not need sudo before 'run-parts' and it should show you the intro messages.
There is also an 'uptime' command that can be added to bash. I couldn't find any short command that just shows how many packages need to be updated and whether system needs a restart.

Hmm it seems like php -i is printing all the environment variables and SSH_ORIGINAL_COMMAND ends up being our SSH wrapper command, and the terminal subsequently interprets this device control string sequence when this is printed out - so it attempts to bootstrap the session.

I think @gagata actually submitted a patch for next week's release that might prevent that from happening! Should be available on Wednesday.

Warp needs to add the ability to run when you have your own remote command set, until they figure that out a cludge would be for them to add -o RemoteCommand=none to their ssh commands, which would disable your command but let their stuff work.

@pys1992 we can keep the issue in #1171 actually. This discussion was made primarily for when we were doing an initial V1 of SSH Support.

@CamJN just added your comment to that GitHub issue as well!