romkatv / zsh4humans

A turnkey configuration for Zsh
MIT License
1.81k stars 116 forks source link

shell crashes with start-tmux enabled #268

Closed owittek closed 1 year ago

owittek commented 1 year ago

Hey!

A while ago I've opened an issue here about the exact same issue.

When spawning a sub-shell with zstyle ':z4h:' start-tmux command tmux -u new -A -D -t main in my .zshrc, the shell crashes/closes itself.

I could confirm this issue happening with the following tools/commands:

I have absolutely no idea why that happens, all I can say is that it happens and I can reproduce it 100% of the times on macOS, Windows & Linux. And I can also confirm that it's not a tmux issue since I can reload my .zshrc with exec zsh after commenting the line at the top out and then I'm able to run the commands without any issues.

I'd really appreciate it if there's a solution other than disabling this feature since I work in tmux 100% of the time.

romkatv commented 1 year ago

It sounds like you want a different command for starting tmux. Go ahead and specify it, or leave the setting at no and start tmux manually.

owittek commented 1 year ago

could you please elaborate how it's related to the tmux command? It does exactly what it's supposed to aside of those edge-cases where a sub-shell spawns.

romkatv commented 1 year ago

Can you describe what you do, what you expect, and what actually happens?

owittek commented 1 year ago

Sure!

I have my terminal open with tmux & z4h. Then I run one of the commands mentioned above, let's go with poetry subshell for example.

I run poetry subshell to source the python-venv file and I expect my shell to now be running from within the virtual env. What actually happens is that the shell suddenly closes without any indicator of why it happens. If I only have a single tmux window open it also closes my terminal.

EDIT: more concise:

romkatv commented 1 year ago

What happens if you set the setting to no and manually run exec tmux -u new -A -D -t main first in the top-level shell, and then in the subshell?

owittek commented 1 year ago

It closes when I run that command in the subshell. So you're definitely right on the part that the command is the issue, not z4h itself.

But I can't find any fixes to that just by googling and reading the tmux manual.

romkatv commented 1 year ago

I don't use tmux myself, so I cannot help you there. If you can figure out which command you want to run, z4h can automate that for you.

owittek commented 1 year ago

Alright, thank you for your help! I'll be closing the issue and look for a solution. Since you're an expert at shell scripting may I ask if you have an idea on how to conditionally run the command? Should I look for env variable or something similar to figure out if I'm in entering a subshell or if tmux has already been run?

Thanks again!

owittek commented 1 year ago

I don't use tmux myself, so I cannot help you there. If you can figure out which command you want to run, z4h can automate that for you.

Actually, is there a solution to not run this command with exec? It seems like tmux automatically detecs potential nesting and warns against it when $TMUX is set but it crashes when run with exec.

romkatv commented 1 year ago

If tmux can detect nesting, so can you. Looking for env vars is the way.

By the way, make sure you are on the newest version of zsh (run z4h update). There was a fix a few weeks ago that might be relevant.

owittek commented 1 year ago

Thanks for the heads-up! I've updated z4h just before creating this issue just to be sure. Should I still be using zstyle ':z4h:' start-tmux command tmux -u new -A -D -t main or just go with a simple tmux -u new -A -D -t main instead?

romkatv commented 1 year ago

The best solution is to use the zstyle but set it conditionally.

owittek commented 1 year ago

Hey @romkatv! I think the cause for this issue might be that the $TMUX env variable is not being set properly when running exec tmux instead of just tmux. Maybe you could add your own variable to z4h to prevent this case from happening to other people?

I fixed it like that:

if [[ -z "$IN_TMUX" ]]; then
    zstyle ':z4h:' start-tmux command tmux -u new -A -D -t main
    export IN_TMUX=1
fi

Greetings!

romkatv commented 1 year ago

How can I reproduce this? Suppose I use this setting:

if [[ -z "$IN_TMUX" ]]; then
  zstyle ':z4h:' start-tmux command tmux -u new -A -D -t main
  export IN_TMUX=1
fi

What do I need to do to get IN_TMUX set and TMUX unset at the same time?

owittek commented 1 year ago

I'm not sure what you mean. The issue is that $TMUX is not being set in the first place when running exec tmux instead of tmux. That is why I've just made up my own env variable to check if I'm within tmux. I've also opened an issue so it might just be a temporary solution

romkatv commented 1 year ago

The issue is that $TMUX is not being set in the first place when running exec tmux instead of tmux.

What steps do I need to perform to reproduce this?

owittek commented 1 year ago

it sets no env variable for me.

romkatv commented 1 year ago

Thank you! I've reproduced this. This is a bug in zsh4humans. Will try to fix later this week.

owittek commented 1 year ago

I'm thanking you for your hard work and this amazing shell setup! Feel free to contact me if I can help you somehow.

owittek commented 1 year ago

Also I'm reopening it while you're working on a fix.

romkatv commented 1 year ago

Thank you! I've reproduced this. This is a bug in zsh4humans. Will try to fix later this week.

I've fixed this issue. I don't know if this also fixes the original issue you were having (you didn't provide instructions for that, so I cannot try to reproduce it).

owittek commented 1 year ago

Thank you! I've reproduced this. This is a bug in zsh4humans. Will try to fix later this week.

I've fixed this issue. I don't know if this also fixes the original issue you were having (you didn't provide instructions for that, so I cannot try to reproduce it).

I assume that the original issue has been occuring due to the env variable missing. Are the changed available via z4h update?

EDIT: I've also provided the steps for the original issue up here.

romkatv commented 1 year ago

I assume that the original issue has been occuring due to the env variable missing.

Maybe. I cannot confirm or deny this.

Are the changed available via z4h update?

Yes.

owittek commented 1 year ago

$TMUX seems to be available now but the issue with my shell/terminal closing is still persistent.

romkatv commented 1 year ago

Make sure you know which tmux commands you want to be executed in each shell and are able to execute them manually. If it works fine when doing things manually but you cannot force z4h execute these commands for you, provide instructions how to reproduce the issue and I'll take a look.

owittek commented 1 year ago

Make sure you know which tmux commands you want to be executed in each shell and are able to execute them manually. If it works fine when doing things manually but you cannot force z4h execute these commands for you, provide instructions how to reproduce the issue and I'll take a look.

Tmux crashes for me even if I run the commands manually, but only if I use exec as to why I think it's an issue with tmux itself.

steps to reproduce:

If I remove the exec keyword it warns me about nesting but like that it just crashes.

romkatv commented 1 year ago

This is working as intended. Simply don't run tmux when you are already in tmux.

owittek commented 1 year ago

Please compare the difference in behavior between

and

In the first case I get a warning and no nesting happens. In the 2nd case it crashes. This is an issue because when using z4h with the tmux autorun it will always crash when entering a subshell because it tries to run exec tmux ... when I'm already in tmux.

romkatv commented 1 year ago

Plain tmux and exec tmux are working as intended. There is no issue there. If you are using tmux manually, simply don't run tmux when you are already in tmux.

My previous comment still stands: https://github.com/romkatv/zsh4humans/issues/268#issuecomment-1531346990. So far, you didn't seem to have found which manual commands you want executed. The ones that you tried either exit your shell or print errors. You need to find commands that actually work.

romkatv commented 1 year ago

This is an issue because when using z4h with the tmux autorun it will always crash when entering a subshell because it tries to run exec tmux ... when I'm already in tmux.

How can I reproduce this?

owittek commented 1 year ago

My previous comment still stands: #268 (comment). So far, you didn't seem to have found which manual commands you want executed. The ones that you tried either exit your shell or print errors. You need to find commands that actually work.

The issue is that I'm NOT using tmux manually. z4h runs exec tmux ... again when I enter a subshell which crashes the entire session.

This is an issue because when using z4h with the tmux autorun it will always crash when entering a subshell because it tries to run exec tmux ... when I'm already in tmux.

How can I reproduce this?

run exec tmux inside of a tmux session and see what happens to your session.

EDIT: Running exec tmux manually is just for demonstration. If you want to see what I'm experiencing you would have to install poetry & run poetry shell inside of a poetry python project.

romkatv commented 1 year ago

run exec tmux inside of a tmux session and see what happens to your session.

Simply don't do that.

You earlier said that z4h runs exec tmux automatically when the shell is already in tmux. How can I reproduce this?

owittek commented 1 year ago

run exec tmux inside of a tmux session and see what happens to your session.

Simply don't do that.

You earlier said that z4h runs exec tmux automatically when the shell is already in tmux. How can I reproduce this?

Gotchu, try using any cli tool that spawns a subshell with its command while having the tmux autostart enabled in z4h.

I have a python project that uses poetry for dependency management and running poetry shell enters the python virtual environment which triggers a reload of the rc file within the subshell.

romkatv commented 1 year ago

I don't use poetry but I'm willing to install it if there is no other way to reproduce the problem. Could you list all steps that are necessary to reproduce the problem? It should look like this:

  1. Install poetry. Make sure that which poetry works.
  2. Run this command: ....
  3. Run this command: ....
  4. Etc.
  5. Run this command poetry shell. Notice that the shell dies. This is the problem. I want this shell to not die.
owittek commented 1 year ago

Sure! I'm assuming you have python installed on your system.

  1. Install poetry: curl -sSL https://install.python-poetry.org | python3 - Taken from here in case you want to double-check the command
  2. cd into your test directory, e.g.: mkdir /tmp/test && cd /tmp/test
  3. poetry init & choose the default options, it doesn't really matter
  4. poetry install
  5. poetry shell -> this will trigger kill the shell.
romkatv commented 1 year ago

Thanks for the instructions. I didn't reproduce the exact problem but I see how various bad things can happen when poetry shell creates a TTY (I wonder why it does that).

Does this do what you want?

if [[ $POETRY_ACTIVE == 1 ]]; then
  zstyle ':z4h:' start-tmux no
else
  zstyle ':z4h:' start-tmux command tmux -u new -A -D -t main
fi
owittek commented 1 year ago

Thanks for looking into this!

I'd rather stick to the solution I mentioned above of setting my own env variable since this is a more general problem. As written in the initial issue, I have also experienced this behavior in toolbox and there might be other tools that also cause this issue.

romkatv commented 1 year ago

Ah, so you already have a config that does what you need? So there is no problem?

owittek commented 1 year ago

I figured this out yesterday and shared it here haha, maybe it's worth adding directly to z4h to prevent this case from happening.

romkatv commented 1 year ago

I cannot add this to z4h because it'll work incorrectly when you launch a terminal from another terminal.

Closing as there is nothing to do here.