MSYS2-packages: bash causing garbage output in TUI applications

hi!

Problem

bash 5.1.8 caused applications to output garbage (raw color codes i guess)
current bash 5.2.9(1)-release (x86_64-pc-msys) is running that fine.

But neither the actual cause, nor the fixing commit was not documented.

Filed issues elsewhere

Action

Do you have any idea on what might have caused/fixed that? i tried looking at commit history for MSYS2-packages/bash but couldnt find out much relevant stuff from commit messages
Ideally, I want to know/find out which commit fixed the issue But knowing the oldest fixing release version would be good too.
How can i install the older version of a package? Again, ideally, i would have wanted to try running git bisect here, but i don’t know building etc, so, i will just suffice at running only the prebuild package versions.

About this issue

Original URL
State: closed
Created a year ago
Comments: 21 (6 by maintainers)

Most upvoted comments

I think you’ll find that the “fix” came with an updated msys2-runtime version (you can get the version, minus patch level, with uname -r). It seems around 2.37 announced dropping vista support, which corresponded to a Cygwin update (which in turn corresponded to an msys2-runtime update). I would bet that it was probably https://cygwin.com/pipermail/cygwin-patches/2022q2/011935.html that fixed this

jeremyd2019 on Jan 27, 2023

i managed to reproduce the bug with gfw 2.31.1 … i will try narrow it down to the fixing version… then will file the bug with upstream gfw…

install the version of gfw in a test directory (warning: do NOT use the gfw installer version - it will previous install)
navigate to gfw/bin in explorer
write click > launch wezterm (terminal here)

cmd> hx
# works

cmd> bash
# launches bash from current (gfw/bin) folder

$ bash --version
GNU bash, version 4.4.23(1)-release (x86_64-pc-msys)

$ hx
# mentioned bug

$ :q
# to exit from that garbage output

gfw	bash	date	buggy?	remark
2.31.1.1	4.4.23(1)	March 27th 2021	buggy
2.34.0.1	4.4.23(1)	November 15th 2021	buggy	hmm? same bash version?
2.39.1.1	5.2.12(1)	Jan 17, 2023	okay
2.37.2.2	5.1.16(1)	August 11th 2022	okay

following the remark above, i traced down the gfw release notes (glad the versions of individual packages are shared there), and found that the significant bash version change only took place at version “gfw 2.37.2 (July 12th 2022)”: from bash 4.4 to bash 5.1 patchlevel 016. Which means, it can be within suspicion range.

wait, why from documenting, i got drowned into looking for bash version again. ugh. looking at other stuff now 🤦

gfw	date	buggy?	remark
2.36.1.1	May 9, 2022	yes	“comes with patch level 4 of MSYS2 runtime” `bash 4.4.23(1)`
2.37.1.1	Jul 12, 2022	no	“” `bash 4.4.23(1)`

goyalyashpal on Jan 27, 2023

So, bash might not be the culprit… Now that i have access to my pacman logs, do u have any other suspected package whose update log i should check for?

I would suspect msys2-runtime, the terminal/pty/console code in upstream cygwin gets a lot of fixes, and is mostly inscrutable to anyone but the author.

How can i install the older version of a package? Again, ideally, i would have wanted to try running git bisect here, but i don’t know building etc, so, i will just suffice at running only the prebuild package versions.

In general, look at package files in (in this case) https://repo.msys2.org/msys/x86_64/, pick one, and install it via pacman -U <URL>. It may not be that simple due to dependencies between packages, you could easily get your install into a broken state that way. Recommend using a temporary installation for such testing so you can just delete it without much loss if things go wrong, or once you’re done.

jeremyd2019 on Jan 26, 2023