Bash commands entered while previous command is executing doesn't resolve afterwards (2.42)

ckorris-imt commented 1 year ago

While using the Bash terminal in 2.42, I am not able to "stack" commands, where if I enter a command that takes some time to execute, and while it's executing, enter a second command and press enter, the second command will resolve after the first is done. In 2.42, the second command is ignored.

This happened after upgrading after a fresh Windows install. However, I verified that going back to 2.41 removes the issue, and then coming back to 2.42 brings the issue back. I use all default settings.

[x] I was not able to find an open or closed issue matching what I'm seeing.

Setup

Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

Version 2.42.0. Uninstalling to 2.41.0 solved the problem. Both 64-bit. I had previously tried uninstalling and reinstalling, clearing my settings, etc. Doing the exact same thing but with 2.41.0 fixed it, Doing the exact same thing again with 2.42 brought it back.

$ git --version --build-options

git version 2.42.0.windows.2
cpu: x86_64
built from commit: 2f819d1670fff9a1818f63b6722e9959405378e3
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon

Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

Windows 10 64-bit

$ cmd.exe /c ver

Microsoft Windows [Version 10.0.19045.3324]
(c) Microsoft Corporation. All rights reserved.

What options did you set as part of the installation? Or did you choose the defaults?

I chose all the defaults - MinTTY, Vim, etc.

# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
> type "$env:USERPROFILE\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt

Possibly relevant, note that I uninstalled 2.41 and reinstalled 2.42 for the purposes of verifying that it was the problem and also so that I could fill out this bug report, hence not much being configured. But I can indeed reproduce the issue again. 

$ "C:\Program Files\Git\etc\install-options.txt"
C:\Program Files\Git\etc\install-options.txt: line 1: Editor: command not found
C:\Program Files\Git\etc\install-options.txt: line 2: Custom: command not found
C:\Program Files\Git\etc\install-options.txt: line 3: Default: command not found
C:\Program Files\Git\etc\install-options.txt: line 4: Path: command not found
SSH: Could not resolve hostname Option:: Name or service not known
C:\Program Files\Git\etc\install-options.txt: line 6: Tortoise: command not found
curl: (3) URL rejected: Port number was not a decimal number between 0 and 65535
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:--  0:00:01 --:--:--     0curl: (6) Could not resolve host: OpenSSL
C:\Program Files\Git\etc\install-options.txt: line 8: CRLF: command not found
Bash: Terminal: No such file or directory
git: 'Pull' is not a git command. See 'git --help'.

The most similar command is
        pull
C:\Program Files\Git\etc\install-options.txt: line 11: Use: command not found
C:\Program Files\Git\etc\install-options.txt: line 12: Performance: command not found
C:\Program Files\Git\etc\install-options.txt: line 13: Enable: command not found
C:\Program Files\Git\etc\install-options.txt: line 14: Enable: command not found
C:\Program Files\Git\etc\install-options.txt: line 15: Enable: command not found

Any other interesting things about your environment that might be related to the issue you're seeing?

insert your response here

Details

Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

Bash. I have not tried others.

What commands did you run to trigger this issue? If you can provide a Minimal, Complete, and Verifiable example this will help us understand the issue.

It happens with any combination of commands where the first takes enough time for you to be able to enter a second command and press enter. The combo I use the most to test is `git fetch` followed by `git status`. But it happened with plenty of other combinations, I have not seen it work as expected with any combination.

What did you expect to occur after running these commands?

After typing git fetch, pressing enter, and then typing git status and pressing enter before the fetch was finished, I expected it to then complete the status command afterwards.

What actually happened instead?

After the fetch was done, it did not do anything, as if I had not entered a second command.

If the problem was occurring with a specific repository, can you provide the URL to that repository to help us with testing?

It it not repository specific.

dscho commented 1 year ago

If this reproduces with regular Cygwin, it is probably something we have to live with.

dscho commented 1 year ago

If this reproduces with regular Cygwin, it is probably something we have to live with.

@ckorris-imt does it reproduce with regular Cygwin?

ckorris-imt commented 1 year ago

@dscho Haven't yet had a chance to try but I've got a reminder set on my phone to do it soon.

emerick commented 1 year ago

This has been happening to me as well. I started noticing it in 2.41. I feel like it got slightly better in 2.42, but it's still a major problem. I'm unable to repro the issue in Cygwin 3.4.9.

dscho commented 1 year ago

This has been happening to me as well. I started noticing it in 2.41. I feel like it got slightly better in 2.42, but it's still a major problem. I'm unable to repro the issue in Cygwin 3.4.9.

Did you enable pseudo Console support?

emerick commented 1 year ago

Did you enable pseudo Console support?

Not that I'm aware of. I just installed the same as always. This is on Windows 11, BTW.

dscho commented 1 year ago

Did you enable pseudo Console support?

Not that I'm aware of. I just installed the same as always. This is on Windows 11, BTW.

For various reasons, Git for Windows still defaults to turning off Pseudo Console support, while Cygwin is "all in". Could you reinstall Git for Windows, toggling Pseudo Console support on, and test again, please?

emerick commented 1 year ago

For various reasons, Git for Windows still defaults to turning off Pseudo Console support, while Cygwin is "all in". Could you reinstall Git for Windows, toggling Pseudo Console support on, and test again, please?

Just did that and it seems much better now, thank you for the tip!

ckorris-imt commented 1 year ago

That is confirmed to be the fix on my end, as well. Thank you!

kriek commented 1 year ago

Hi there,

here are other problematic use cases probably sharing the same root cause:

A commit-msg hook calling git (any subcommand with no - or redirected to file - output) will mess up carriage return in the stdout result. My real-world example is the Gerrit one. A minimized example is a commit-msg with a "git stripspace" call resulting in shifted shell prompt:
```
$ git commit -m 'Commit header' --allow-empty
[master 8d021b2a] Commit header
                           $
```
A commit-msg with multiple git commands outputing to stdout will fail with a hidden bad stdout descriptor error. I don't have a real-world use case but I discovered that while investigating the previous problem and I thought it was worth sharing. Here would be a commented commit-msg demonstration hook:
```
#!/bin/sh
git log -1 # ok, visible in stdout
git log -1 2> error.txt # broken, the stderr content is "fatal: write failure on 'stdout': Bad file descriptor"
echo $? > retcode.txt # the retcode is 128
```

Advanced aliases calling git multiple times are broken; the bad stdout descriptors striking again. I do have real-world personal aliases affected (not worth sharing here). Short demonstration:

$ git config -l | grep broken
alias.not-broken=!f() { git log -1;}; f
alias.broken=!f() { git log -1 && git log -1;}; f
$ git not-broken
commit 555ea07c (HEAD -> master)
Author: Me
Date:   Wed Sep 20 12:25:35 2023 +0200

Commit header
$ echo $?
0
$ git broken
commit 555ea07c (HEAD -> master)
Author: Me
Date:   Wed Sep 20 12:25:35 2023 +0200

Commit header
$ echo $?
128
$

Those new use cases all share the so-far discovered workarounds:

Revert to version 2.41.
Enable pseudo console support.

I hope this helps assessing the issue severity and moving its analysis forward. To me, that 2.42 git version is too broken to be used without pseudo console support. Note that I have no objection activating it, quite the opposite given the side benefits. It's just that the "experimental" classification in the installer kept me away from it so far. If Cygwin opted for it by default, I guess it's not that experimental anymore.

dscho commented 1 year ago

I guess we'll have to switch to enabling Pseudo Console support for all ☹️

kriek commented 1 year ago

I guess we'll have to switch to enabling Pseudo Console support for all ☹️

What are the Pseudo Console activation drawbacks?

dscho commented 1 year ago

What are the Pseudo Console activation drawbacks?

I am still not convinced of the quality of the code. There has been a relatively steady stream of bug reports followed up by fixes that were neither well-described nor well-contained, it often seemed as if they were only addressing symptoms and not root causes.

But that steady stream did wane a little. What has increased are the problems with non-Pseudo Console code that was supposed to be left alone by Pseudo Console support but wasn't.

So at this stage it might be a "damned if you don't, damned if you do" situation.

mfriedrich74 commented 1 year ago

For how long was the pseudo console support enabled due to another bug that switched the setting? Maybe factor that in in your decision? It may have been longer under test than thought.

Best regards, Mike

On Fri, Sep 22, 2023, 8:29 AM Johannes Schindelin @.***> wrote:

What are the Pseudo Console activation drawbacks?

I am still not convinced of the quality of the code. There has been a relatively steady stream of bug reports followed up by fixes that were neither well-described nor well-contained, it often seemed as if they were only addressing symptoms and not root causes.

But that steady stream did wane a little. What has increased are the problems with non-Pseudo Console code that was supposed to be left alone by Pseudo Console support but wasn't.

So at this stage it might be a "damned if you don't, damned if you do" situation.

— Reply to this email directly, view it on GitHub https://github.com/git-for-windows/git/issues/4603#issuecomment-1731333703, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABZH5SGEPDZUKX3TVLSKTC3X3WADRANCNFSM6AAAAAA4VAFZ4M . You are receiving this because you are subscribed to this thread.Message ID: @.***>

dscho commented 12 months ago

For how long was the pseudo console support enabled

As per the explanation in https://github.com/git-for-windows/build-extra/pull/522, it was enabled by mistake in v2.41.0 and that bug was fixed in v2.42.0(2). That's equivalent to about 8 weeks and while v2.41.0's installer was downloaded over 2.7 million times, the v2.42.0 one was downloaded only just over 800k times. And since I cannot add any telemetry without having to fear for my own life at the hands of some very opinionated people, I cannot say how many of those downloaded installers were actually run, let alone in how many instances they were followed by frustrated downgrades to the previous Git for Windows version.

In other words: I am deprived of any dependable data to support making that decision.

git-for-windows / git

Bash commands entered while previous command is executing doesn't resolve afterwards (2.42) #4603

Setup

Details