[Cygwin] Prezto makes zsh hang at exit

[alixinne]

Description

On Cygwin, when zsh is used with prezto, exiting the shell (via exit or Ctrl+D) hangs the shell, and the process has to be terminated. At least sorin and pure themes are affected, even using the default configuration.

Expected behavior

When exiting the shell via exit or Ctrl+D, the shell process terminates normally.

Actual behavior

When exiting the shell via exit or Ctrl+D, the zlogout message is displayed but the process gets stuck without exiting.

Steps to Reproduce

1. Install cygwin with the zsh package (currently 5.3-1, but 5.1.1-1 is affected too)
2. Install prezto by following the instructions
3. Open a shell and try to exit it via exit or Ctrl+D. It should hang, and the terminal window should stay open.

Git bisect result

This issue was not happening before I updated my prezto working copy. According to a git-bisect between the revisions before and after the update, 9bdc1b3 is the first revision affected by this issue:

9bdc1b35d51407515edb5e82dd3f8635fd771511 is the first bad commit
commit 9bdc1b35d51407515edb5e82dd3f8635fd771511
Author: Kaleb Elwert <[email protected]>
Date:   Mon Jul 24 11:55:02 2017 -0700

    Migrate sorin prompt to zsh-async (#1385)

    This includes some improvements by @indrajitr in addition to the main migration.

    The first step was to avoid PROMPT and RPROMPT modification when possible (which may help resolve some other issues as well relating to zsh crashes with the sorin prompt) then update the displayed git information in a separate variable rather than a command.

    We use zsh-async for creating and running background tasks. The sorin prompt uses it to update git info without blocking the prompt from displaying (because of how long it can take). In the future it may be worth moving more tasks and more prompts to using this.

    The move to zsh-async does make the git prompt slower in some circumstances (most noticeable in large repos), but this is a worthwhile tradeoff to avoid the cache file which had a number of potential security holes.

    We have also switched to adding zsh-async as an external submodule (rather than the version bundled with pure) which may cause some migration headaches, but it will be worth it in the long run.

:100644 100644 46e6a0e69d7da7a7610cb7b85816ee96d5556da7 365b059226a226575fa09bae58691e60406e908c M      .gitmodules
:040000 040000 1a718dd9075fc540c8d59fa584c157a1434b7678 a6ab330ba6ca36d39ec83eb468f84d4d326f0491 M      modules

Versions

• Prezto commit: 1098644
• ZSH version: zsh 5.3 (x86_64-unknown-cygwin), cygwin version: 5.3-1
• OS information: Windows 10 Pro x64 build 1709

[belak]

Thanks for running that bisect... I assume this is a regression in zsh-async because we stopped using the version of async bundled with pure in that commit, as well as updating the sorin prompt to use async rather than a custom solution. Do you still see issues with pure before that commit?

There are also a number of known issues in 5.3 (which I think were fixed in 5.3.2).

I don't have a cygwin environment to test with right now, so if you get a chance to bisect zsh-async before me, I'd be interested in the results.

[alixinne]

pure seems to have been broken since 02c5f77 on Cygwin according to bisect. However before that the async functionality of pure was also broken, so that's probably why the bug was not happening. I don't think the pure theme has ever been working on Cygwin.

Here is the bisect run script that I used for these tests.

Note 1: launching an xterm is the "most reliable" way I found to allocate a fully-working tty from a script that's run by git bisect.

Note 2: apparently git bisect is not a big fan of submodules. This script forces the checkout of submodules at each step to ensure we are testing the repository at its current revision, including all submodules.

#!/bin/bash

PROMPT_NAME=sorin
if [ -n "$1" ]; then
  PROMPT_NAME="$1"
fi

DIR=$(dirname "$BASH_SOURCE[0]")

# Ensure the modules are up-to-date
(cd $DIR && git submodule update --init --recursive)

# Ensure the prompt is set to PROMPT
sed -i "s/zstyle ':prezto:module:prompt' theme .*/zstyle ':prezto:module:prompt' theme '$PROMPT_NAME'/" $HOME/.zpreztorc

# Send some commands and an exit to ZSH
xterm -e "echo -e 'exit\n' | zsh -is" &

# Record the PID
XTERM_PID=$!

# Wait for a few seconds
sleep 5

# Is the process still there?
if [ -e /proc/$XTERM_PID ]; then
  # Kill xterm
  kill -9 $XTERM_PID
  RESULT=1
else
  # The process is not there
  echo "ZSH exited" >&2
  RESULT=0
fi

# Restore the prompt
(cd $DIR && git checkout runcoms/zpreztorc)

exit $RESULT

[GaryFurash]

I have the same issue w/ similar configuration.

[kwonoj]

I have similar issues as well on msys2 and back to previous version doesn't rely on zsh-async.

Problem is in zsh-async indeed, internally zsh-async uses zpty for asynchronous task execution but zpty is nearly not working on windows at all - either it doesn't report back job results, or just not start at all. (https://github.com/msys2/msys2/issues/84 / sindresorhus/pure#198 (comment) ). It doesn't seem like to able to get workable zpty on cygwin/msys2 unfortunately.

[belak]

This is unfortunate. I really like the improvements we were able to make with async, but it's pretty unreasonable to ask for all Windows users to not use the default prompt. I'm pretty busy, but I'll do my best to look into this at some point.

[kwonoj]

@belak I've noticed this prompt module(https://github.com/agkozak/agkozak-zsh-theme) came to across same issue and resolved by having separate async execution path for non-zpty-supported system, looks quite promising. Is it considerable to port those async lib into sorin? for existing users could use zsh-async still will works same. I'd give myself a try but lacks of my knowledge around zsh will makes quite tough to try port those.

[kwonoj]

may related with #1523 as well - support async worker for non-pty compatible environment.

[belak]

Can you try the code in #1805 and let me know if that fixes the issue for you? It's a brand new implementation which doesn't use zsh-async at all.

[kwonoj]

It doesn't seem to create hanging zsh processes, but also git status is not appear as well.

[alixinne]

I can confirm, no hanging process but no git status.

As a side note, holding Shift while clicking the close button or pressing Alt+F4 forces the terminal emulator to close without needing to go through the Task Manager, although it leaves zombie zsh processes behind.

[jeffwidman]

Does the fix in #1810 help for this particular issue?

[alixinne]

I merged in that branch but no change, no git status.