Open chuimarv opened 1 year ago
dannyneira
commented
1 year ago We have had a number of issues like this so it may be tough to reproduce on our end. We'll post any updates or followup question here.
Meanwhile, you can disable the SSH Wrapper by navigating to Settings > Features. Blocks will stop working but with it disabled, SSH should work as normal.
pka420
commented
1 year ago I got the same problem with the same OS and zsh. In addition to above, the screen get stuck when the session expires.
Using /usr/bin/ssh instead of ssh is a workaround, but you loose some of the perks of warp interactive sessions.
zachbai
commented
1 year ago Shot in the dark here -- could you try using Warp's subshell feature instead?
If you add command ssh .* as an "added subshell command" (per the docs here), and then try ssh'ing into the remote host with the same command, just prefixed with command e.g. command ssh me@myremotehost, you'll see a banner prompting you to "Warpify" your session -- you should do so after entering your password for the host (if there is one)
If this works, then it somewhat narrows down the issue to the SSH wrapper implementation (and it could also provide a better workaround then using /usr/bin/ssh without most of Warp's features
sudoHackIn
commented
1 year ago I have the same issue with os monterey 12.6.3 and same shell version (zsh 5.8.1 (x86_64-apple-darwin21.0), warp v0.2023.07.04.08.03.stable_02. I was trying to use ssh as "subshell comand", as @zachbai mentioned, but there were a big issues with spaces, rendering and shell clearing
zachbai
commented
1 year ago @sudoHackIn The "Warpify" process is failing because for some reason on that remote host, PROMPT_COMMAND is set as readonly -- probably in the user/host's .bashrc or .bash_profile. Unfortunately there's no easy fix for this -- it's likely that PROMPT_COMMAND is set as readonly intentionally by whoever administrates that machine (it might do some logging for security/monitoring, for example).
A possible workaround -- not sure if it will definitely work but worth a try -- is to try first spawning a subshell without the default config (e.g. with `bash --rcfile ''), and then trying to warpify that subshell with the keybinding/button.
So you'd do somehting like:
bash --rcfile ''
aldebout
commented
1 year ago @zachbai if that can help with troubleshooting, I tried exactly your steps because I had the same problem.
The resulting warpified shell is not really interactive: I can type characters but I can't press return. Ctrl-D or ctrl+C don't work, I have to close the tab.
The same server used to have no problem with the wrapper a few months ago.
macOS 13.4.1 warp v0.2023.07.18.08.03.stable_00 zsh 5.9 + OMZ
Remote environment: CentOS Linux release 7.9.2009 GNU bash, version 4.2.46(2)-release (x86_64-redhat-linux-gnu)
zachbai
commented
1 year ago @aldebout That's super helpful thanks. It looks like our initialization script fails when certain env vars are readonly -- I'll look into a fix for this.
albnorleku
commented
1 year ago Is there an update on this, I have the above issue of stuck in starting shell
ElijahLynn
commented
8 months ago
Discord username (optional)
No response
Describe the bug
When I start ssh into remote desktop on Warp, new uneditable block with "Starting shell..." appears below the actual remote shell block.
To reproduce
ssh into any remote desktop
Expected behavior
I expect to see just the remote shell block at the bottom, without "Starting shell..."
Screenshots
No response
Operating system
MacOS
Operating system and version
12.6.5
Shell Version
zsh 5.8.1
Current Warp version
v0.2023.05.23.08.05.stable_00
Regression
Yes, this bug started recently or with an X Warp version
Recent working Warp date
No response
Additional context
No response
Does this block you from using Warp daily?
No
Is this a Warp specific issue? (i.e. does it happen in Terminal, iTerm, Kitty, etc.)
No, this same issue happens in Warp and other terminals.
Warp Internal (ignore): linear-label:b8107fdf-ba31-488d-b103-d271c89cac3e
None