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:

https://github.com/warpdotdev/Warp/assets/10574322/6b6ed4b9-e590-41f0-b44e-b9c783bcb585

[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

[mmenendezg]

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.

[zachbai]

I was able to confirm with a couple users that adding the RC file snippet used for "Automatically Warpify subshells" (see docs here) works as a workaround.

So, if you're using zsh for instance, adding

printf '\eP$f{"hook": "SourcedRcFileForWarp", "value": { "shell": "zsh"}}\x9c'

To the bottom of your ~/.zshrc might fix the issue (note in this case, when running a local zsh subshell, poetry or otherwise, Warp will automatically attempt to warpify it.

I'll still look into a fix for the issue that doesn't require the RC file change, but hopefully this alleviates the issue in some cases.

[mmenendezg]

Hi @zachbai,

Everything is working well on my end after adding the RC file snippet at the end of the ~/.zshrc file.

Thanks for the assistance.

[oli-clive-griffin]

Thanks, this also fixed warp freezing on me when running pipenv shell then accepting the warpify prompt

[GROOOOAAAARK]

Hi !

Thanks for the work on Warp, no regret since moving to this tool from iTerm. As some of you guys I encountered the issue with sub shell freezing through the use of pipenv, is there any update on this subject apart from the hack mentioned above ?

Thanks !

[aminya]

I have the same issue with poetry shell even though I have the following at the end of my bashrc.

printf '\eP$f{"hook": "SourcedRcFileForWarp", "value": { "shell": "bash"}}\x9c'

I am using the latest version of poetry on Linux.

My solution has been to create the following setup.bash script to fix the issue

# Create a virtual environment
poetry config virtualenvs.in-project true
poetry env use python3

# Install dependencies
poetry install

if [[ $TERM_PROGRAM == "WarpTerminal" ]]; then
    # if the terminal program is WarpTerminal, do not create a shell due to https://github.com/warpdotdev/Warp/issues/3105
    source $(poetry env list --full-path | head -n 1 | sed 's/ (Activated)//')/bin/activate
else
    # Crate a new shell via poetry
    poetry shell
fi

Then I can run source ./setup.bash

[artekr]

Still having this issue. I got completely stuck on this step.

poetry shell command works just fine in mac's default Terminal app

[artekr]

I was able to confirm with a couple users that adding the RC file snippet used for "Automatically Warpify subshells" (see docs here) works as a workaround.

So, if you're using zsh for instance, adding

printf '\eP$f{"hook": "SourcedRcFileForWarp", "value": { "shell": "zsh"}}\x9c'

To the bottom of your ~/.zshrc might fix the issue (note in this case, when running a local zsh subshell, poetry or otherwise, Warp will automatically attempt to warpify it.

I'll still look into a fix for the issue that doesn't require the RC file change, but hopefully this alleviates the issue in some cases.

Update: I'm using oh-my-zsh, so adding the following script at the bottom of my ~/.zshrc file as @zachbai suggested solved the issue.

printf '\eP$f{"hook": "SourcedRcFileForWarp", "value": { "shell": "zsh"}}\x9c'

The only minor annoying part is this long output will be shown every time I spawn a new shell, but that's minor.

[vpmartin]

+1 for @artekr's remark. Adding the line at the end of ~/.zshrc does the trick but the long output is very annoying.

Currently testing Warp as a replacement for iTerm2, mostly for the modern looks and the AI features, but it truly removes a lot of the looks wow-effect to have this pop up on every new shell session. Minor but annoying.

[zachbai]

Thanks for the feedback! It should be straightforward to add a "Don't show again" option to that output block -- will track this with the team internally.

[paul-voelker]

For me it looks like having this pyenv related line in my ~/.zshrc causes the poetry subshell warpify to break:

eval "$(pyenv virtualenv-init -)"

When I remove this line the warpify works just fine

[IvanildoBarauna]

Same problem here, when adding:

printf '\eP$f{"hook": "SourcedRcFileForWarp", "value": { "shell": "zsh"}}\x9c'

At the end of my .zshrc the problem seems to have been solved, it's only annoying the first time because it breaks due to the end of the command not being recognized, but just press Enter and in the next sessions it will warpfy correctly.

[vacarme]

For me it looks like having this pyenv related line in my ~/.zshrc causes the poetry subshell warpify to break:

eval "$(pyenv virtualenv-init -)"

When I remove this line the warpify works just fine

I do not have pyenv-virtualenv and poetry shell does not work in warp, even if I disable pyenv it's still not working, seems unrelated to pyenv to me.

[warrenbhw]

+1, same issue here

[javierjavier]

same issue with pixi shell. workaround doesn't work, just hangs at 'Starting shell...'