Open MarcBickel opened 7 months ago
Hey @MarcBickel sorry to hear about this blocker. You may have one or more version of zsh installed, I suggest you run which zsh
and then put the result into Warp > Settings > Features > Sessions > Startup shell for new sessions. This way, your Warp will always try and open the primary/default version of zsh. In my example below it was /opt/homebrew/bin/zsh
, but yours may be different.
Please let me know if this helped with your issue loading zsh.
Hi @dannyneira, thanks for your answer 😄 Unfortunately that's not it, I only have one version of zsh intalled, /bin/zsh
. It is also detected fine when I manually select zsh as startup shell (not default and not custom).
Just to reiterate, when I just open a new tab in an already existing window/session (with cmd+t), then the zsh shell gets loaded up completely fine. This bug really only happens in the two situations I describe in my initial post. All the others use cases are fine (from the solution you describe no use case should have worked, from what I understand?).
Let me know if I can provide more information, would be glad to do so
PS: I see that I said workflow in my first post, but I meant launch configuration, sorry about that.
Here are the content of the launch configuration file:
# Warp Launch Configuration
#
#
# Use this to start a certain configuration of windows, tabs, and panes
# Open the launch configuration palette to access and open any launch configuration
#
# This file defines your launch configuration
# More on how to do so here:
# https://docs.warp.dev/features/session-management/launch-configurations
#
# All launch configurations are stored under ~/.warp/launch_configurations/
# Edit them anytime!
#
# You can also add commands that run on-start for your launch configurations like so:
# ---
# name: Example with Command
# windows:
# - tabs:
# - layout:
# cwd: /Users/warp-user/project
# commands:
# - exec: code .
---
name: Smart Contract Dev
windows:
- tabs:
- layout:
cwd: /Users/marc/Documents/fume-smart-contracts
- layout:
cwd: /Users/marc/Documents/fume-smart-contracts
- layout:
cwd: /Users/marc/Documents/fume-smart-contracts
Thanks for clearing that up, I tried your launch config and had no issues with zsh failing to load. If the issue isn't with your startup shell there is a good chance you have an unsupported plugin in your ~/.zshrc
file that Warp is unable to parse causing the load times/hangs with zsh.
You can check whether it’s something in your dotfiles by setting up clean configs:
Run echo 'ZDOTDIR=/' > ~/.zshenv
This forces Zsh to run with zero configs.
You can disable parts of your dotfiles just for Warp by using this conditional statement:
# Bash and Zsh
if [[ $TERM_PROGRAM != "WarpTerminal" ]]; then
# > What you want to disable here <
fi
We have a list of incompatible tools here: https://docs.warp.dev/help/known-issues#list-of-incompatible-tools
@dannyneira Thank you for that. Absolutely, if I run with zero .zsh
config, it does work. However, now yarn
is not on the global path anymore for example, so an empty config doesn't do it for my workflow.
I have tried disabling different parts, and it looks like it is related to nvm is my guess. Here is my full .zshrc
file, and whenever I disable the part related to nvm, it does boot up (other things are then bad, but that's not a warp problem). I don't see however anything related to nvm in you known issues, so I am a bit puzzled as to what breaks here
export NVM_DIR="/Users/username/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh" # This loads nvm
# place this after nvm initialization!
autoload -U add-zsh-hook
load-nvmrc() {
local nvmrc_path="$(nvm_find_nvmrc)"
if [ -n "$nvmrc_path" ]; then
local nvmrc_node_version=$(nvm version "$(cat "${nvmrc_path}")")
if [ "$nvmrc_node_version" = "N/A" ]; then
nvm install
elif [ "$nvmrc_node_version" != "$(nvm version)" ]; then
nvm use
fi
elif [ -n "$(PWD=$OLDPWD nvm_find_nvmrc)" ] && [ "$(nvm version)" != "$(nvm version default)" ]; then
echo "Reverting to nvm default version"
nvm use default
fi
}
add-zsh-hook chpwd load-nvmrc
load-nvmrc
export PYENV_ROOT="$HOME/.pyenv"
export PATH="$PYENV_ROOT/bin:$PATH"
eval "$(pyenv init -)"
export PATH="`yarn global bin`:$PATH"
And, do you load this .zshrc
differently between opening a new tab or launching a new launch config or opening warp with the windows from last session? As I said, whenever opening a new tab it works perfectly fine, it's really the case when multiple tabs are open at the same time (That's the common point I see between opening my launch config and restoring the windows from the previous session).
This makes me think, it's not all related to my config file
Thanks for sharing the extra info, As far as I know, the new tab/launch config/reopen after quitting Warp all bootstrap the rc files the same way. I couldn't reproduce the bug with the files you provided.
That being said I did notice an issue with your code ( not sure if it was intentionally changed before you shared with me) on the first line, replace
export NVM_DIR="/Users/username/.nvm"
with export NVM_DIR="$HOME/.nvm"
and it should dynamically set the NVM_DIR based on the logged-in user. Let me know if that helps with your issue.
@dannyneira Thank you for your answer. I did change that part when sharing my code, it is set to my username in my file, just didn't want to share my username. I did change it to your recommendation though, thank you!
I did some more testing and found out something really interesting. When I reopen my old windows after closing down Warp, if the working directory is different, then, there is only one directory which makes the tab hang, the others go along just fine. Same for a launch configuration.
So my guess now is, the launch of zsh depends on where the working directory is. Does the cd in a launch config happen before initializing zsh? If yes, then maybe it's my one directory that's the cause.
I can't share completely the contents of the repo, but it's a fork of https://scaffoldeth.io/, initialised with their npx tool. Do you think something could be messing up the zsh initialisation in there?
EDIT: most likely this repo is the cause, as I created another instance of it without changing anything, and zsh initialisation does hang in there as well
Hi, I have the exact same issue where on the first launch, it says starting zsh and stuck there forever on a new Apple M1 max macbook running macOS 14.3.1, tried echo 'ZDOTDIR=/' > ~/.zshenv
but still no luck
when i tried echo 'ZDOTDIR=/' > ~/.zshenv
, warp is work and the message "starting zsh..." is missing.
thank you very much , your answer is helpful to me
my env: Apple M1 pro macbook running macOS 14.0 /bin/zsh
Thanks for clearing that up, I tried your launch config and had no issues with zsh failing to load. If the issue isn't with your startup shell there is a good chance you have an unsupported plugin in your ~/.zshrc file that Warp is unable to parse causing the load times/hangs with zsh.
You're are right. I was having a similar problem. In my case, it's showing me the massage every time I open it. And the massage doesn't disappear after a while. (I'm using linux)
I just check in my ~/.config/.zshrc . It's running a command every time I open the terminal. Which takes a lot of time to execute. That's the problem.
Thank you for opening this issue and answering this issue.
I was facing this issue as well only for the project folder. I looked into .zshrc and what worked for me was disabling/removing the Yarn's global binary directories in the PATH environment variable.
I very occasionally run into the issue where upon starting Warp all of my tabs remain stuck at the 'starting zsh...' stage. This happens when I have a medium number of tabs open from the previous session (9 in the latest case), and my MacBook (M1 Max, 64G) is very heavily loaded because it just rebooted for a macOS update and concurrently starting about 20 other applications, many of which are not lightweights (IntelliJ IDEA, GoLand, Teams, Discord, Slack, Photos, etc).
In this situation it is entirely understandable that booting up 9 tabs of zsh can take a while, so the initial message does not disturb me at all. The problem is that even if I leave everything and the machine has finished with everything and is back to at least 75% idle, these tabs and their startup do not recover. It seems like some component in that process is timing out and cannot recover even when the load on the system goes away.
If I then quit and restart Warp, all the tabs load properly, but they've all lost their previous working directory and are reset to my default (home) directory. Now having to do a couple of cd
commands isn't a huge deal, but it is annoying, and more so if I was keeping a tab open as a way of reminding myself of things I needed to do.
Discord username (optional)
No response
Describe the bug
In two situations, the message "starting zsh..." stays on the screen, and no command can be entered. The warming "seems like your shell is taking a while to start comes in". No useful information has been found on that link. Outside these two situations, zsh loads fine (such as opening a new tab or window) The two situations are:
This means I always have to close whatever tab I had, and open a new one. Or that custom workflows don't work.
To reproduce
Expected behavior
The message goes away after a couple of seconds, and the warp tab is usable. Or, that the workflow works.
Screenshots
Operating system
MacOS
Operating system and version
14.2.1
Shell Version
zsh 5.9 (x86_64-apple-darwin23.0)
Current Warp version
v0.2024.01.09.08.02.stable_02
Regression
No, this bug or issue has existed throughout my experience using Warp
Recent working Warp date
No response
Additional context
No response
Does this block you from using Warp daily?
Yes, this issue prevents me from using Warp daily.
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:b9d78064-c89e-4973-b153-5178a31ee54e
None