Input stops working after clicking "Warpify" subshell

[darrenburns]

Discord username (optional)

No response

Describe the bug

Clicking "Warpify subshell" seems to prevent me from being able to input anything into the terminal.

To Reproduce

1. I launch a subshell using poetry shell
2. I can type things freely and they appear
3. I click "Warpify subshell"
4. Visually, there are no changes, but...
5. When I type things, nothing happens. Things like ctrl+d to exit the subshell don't work either.

Expected behavior

No response

Screenshots

No response

Operating System

MacOS

Operating System and Version

MacOS 12.6.3

Shell Version

fish, version 3.5.1

Warp Version

v0.2023.05.18.01.08.stable_04

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.)

Yes, this I confirmed this only happens in Warp, not other terminals.

Warp Internal (ignore): linear-label:b8107fdf-ba31-488d-b103-d271c89cac3e

None

[dannyneira]

Hi @darrenburns Sorry about this issue, We're working on it, but if you could, please provide a video/screenshots of the issue to help us understand where it may be failing.

Also, have you tried adding the poetry command in the Settings > Subshell menu?

Any luck with adding the following line to your RC files?

# For zsh subshells, add to ~/.zshrc.
printf '\eP$f{"hook": "SourcedRcFileForWarp", "value": { "shell": "zsh"}}\x9c'

# For bash subshells, add to ~/.bashrc or ~/.bash_profile.
printf '\eP$f{"hook": "SourcedRcFileForWarp", "value": { "shell": "bash"}}\x9c'

# For fish subshells, add to ~/.config/fish/config.fish.
if status is-interactive
  printf '\eP$f{"hook": "SourcedRcFileForWarp", "value": { "shell": "fish"}}\x9c'
end

[jasperanders]

Hey, face the same issue, find a video of the bug below:

Screen.Recording.2023-06-22.at.09.26.52.mov

[ggydush]

Same issue here - seems that when using bash it works, when zsh is default shell, it does not work

[andreale28]

I also faced the same issue wih zsh as default shell.

[ggydush]

This is a hack, but if you just want to activate the environment, you could add something like this to your .zshrc and it will still work:

activate () {
    source $(poetry env list --full-path | head -n 1 | sed 's/ (Activated)//')/bin/activate
}

[jpoutrin]

I have the same issue since renctly upgrading warp, when activating a pipenv shell.

[arthurvasconcelos]

This is a hack, but if you just want to activate the environment, you could add something like this to your .zshrc and it will still work:

activate () {
    source $(poetry env list --full-path | head -n 1 | sed 's/ (Activated)//')/bin/activate
}

I am having the same problem with zsh. Thanks for the hack @ggydush. I've added it to the new Warp Drive, it's easy to find with the command pallet. 😄

[theogbrand]

same issue! zsh as default shell.

[mattflo]

Just trying out Warp after listening to @zachlloyd on the Changelog pod. I immediately ran into this. I'll move forward with the hack, but seeing this sit here for months with no resolution isn't a good sign.

[xm4dn355x]

Same issue

[chriszrc]

Same problem with a docker shell 😥

[miaozasanynoe]

me too

[marlonimg]

Is there an update regarding this? The last version has not solved the issue for me. When running poetry shell the tab freezes and I am not able to interact with Warp, not even to exit the virtual environment.

[zachbai]

Hey all, a couple follow up questions:

• What version of poetry are you using?
• Is poetry shell being invoked from within an SSH session or a docker subshell?
• Is the issue reproducible across other shells? i.e. if the issue's happening with zsh does it reproduce with bash or fish?

When we were building the subshells feature I encountered this issue on occasion and traced the root cause to pexpect (which is a lib used to implement poetry's subshell feature, I filed an issue on pexpect back then here). We ended up implementing a workaround that should have addressed the issue for poetry shell usage within a local (non-SSH) session at least, but seems like that's not the case.