Skip to content

fix: hang at startup if .bashrc contains exec call#527

Open
spicychickensauce wants to merge 3 commits intoelixir-lang:mainfrom
spicychickensauce:fix-hang-on-getting-path-env
Open

fix: hang at startup if .bashrc contains exec call#527
spicychickensauce wants to merge 3 commits intoelixir-lang:mainfrom
spicychickensauce:fix-hang-on-getting-path-env

Conversation

@spicychickensauce
Copy link

See: #340

In my .bashrc I've got this at the end:

# If not running interactively, don't do anything
[[ $- != *i* ]] && return
exec fish

This is one of the recommended ways on how to set up fish on the arch wiki.
But, with this .bashrc, expert hangs indefinitely at startup.

The problem with the original code is the use of the -i flag.
I don't know the original intent behind using that flag here, so instead of simply removing it, I added a timeout + fallback without -i instead.

@spicychickensauce spicychickensauce changed the title Fix hang at startup if .bashrc contains exec call Fix: hang at startup if .bashrc contains exec call Mar 22, 2026
@spicychickensauce spicychickensauce changed the title Fix: hang at startup if .bashrc contains exec call fix: hang at startup if .bashrc contains exec call Mar 22, 2026
@spicychickensauce
Copy link
Author

I fixed the credo warning by extracting the args construction into its own function, should be good now

@katafrakt
Copy link
Contributor

I think interactive flag might be necessary to support mise in "path mode", which relies on the prompt display to activate.

I also wonder if this is the best solution to the problem. Maybe instead there should be a flag passed to expert command, such as expert --stdio --force-non-interactive.

@spicychickensauce
Copy link
Author

I'm also using mise, and it works for me only without the -i flag...

I don't like if users need to configure the right behavior, then it will just not work out of the box for some and the setting will be hard to track down.

Also, a timeout is needed anyway, as without it the whole lsp just hangs, with no logs to even help identify the problem.

@katafrakt
Copy link
Contributor

a timeout is needed anyway, as without it the whole lsp just hangs

I agree with that. But what bothers me is what happens after - removal of -i switch is very arbitrary. What if someone has a condition in .bashrc on -l flag for some reason?

I'm also using mise, and it works for me only without the -i flag...

This is interesting. Maybe I misunderstood how the "path mode" works. How do you set up mise (for bash or for fish)? Can you paste first 4 lines of mise doctor output?
It seems from the problem description that your SHELL env variable is set to bash, not fish, when Expert starts. This is a real problem issue IMO.

I don't like if users need to configure the right behavior

Calling scripts in an interactive shell is also a correct behaviour. Relying on exec in .bashrc will likely cause problems with any software that does that.

Maybe we need EXPERT_SHELL env var for cases like this, akin to MISE_SHELL, so user can override which shell is used by Expert?

@spicychickensauce
Copy link
Author

What if someone has a condition in .bashrc on -l flag for some reason?

It will just run into a timeout in the worst case and fallback to the filter_release_root_from_path() function.

I think removing the -i flag is not arbitrary, as using the flag from scripts is already quite out there.

How do you set up mise (for bash or for fish)?

I set up mise in both bash and fish via mise activate, so all dev tools always have the right paths, no matter which environment.
mise doctor output

version: 2026.3.8 linux-x64 (2026-03-12)
activated: yes
shims_on_path: no
self_update_available: no

It seems from the problem description that your SHELL env variable is set to bash, not fish

Yes, my $SHELL is set to bash. I can't set this to fish because many other tools break if I do. The whole point of my setup is to stay fully compatible with bash for tools and scripts and only use fish interactively. This is the least invasive setup, as recommended by the arch wiki. This is the first time I've run into any issue with this setup.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

3 participants