[question] Missing bash.exe shim after scoop update git

[lxl66566]

I use <scoop>/shims/bash.exe as my default shell. Recently, after running scoop update git, I noticed that bash.exe was removed from the shims folder, which cause my commands to fail.

It seems to be caused by this commit. Was this change intentional or a mistake?

In my opinion, if sh.exe is included in the shims, bash.exe should be included as well.

[z-Fng]

Please refer to discussion #7459 (comment) & #7531 (comment).

[z-Fng]

#7531 (comment)
This is only true if there would be no existing third party integration expecting it to be there, also this means that after installing adding the shims folder to path is not enough which previously was.
So it does not affect the ability of users to use git in new user session, but they actually can not use it right away as they previously could.

It looks like #7459 makes the git manifest in Scoop behave similarly to the official installer, but at the cost of breaking many existing workflows relying on the previous behavior. I'm wondering if we could revert some of the changes, or perhaps keep the shims while adding cmd to the PATH at the same time.

cc @SorYoshino

[SorYoshino]

To be honest, I do not recommend adding bash.exe back to the bin field. The reasons have already been explained in detail in #7459 (comment). For similar cases, sh.exe or an alias can be used as a complete substitute, as they share the same hash. Unlike the removal of cmd\git.exe, this situation does have reasonable alternatives.

As for the issues caused by removing cmd\git.exe, I do not see a problem with adding it back to the bin field. However, I do have some concerns, which are detailed in #7531 (comment).

[z-Fng]

• For users who have WSL installed, invoking bash.exe may start WSL instead of Git Bash. Keeping it in the bin field can therefore cause confusion.

I understand the rationale behind these changes and that there are valid reasons for them. While the previous behavior might have caused confusion for some, the new behavior is now disrupting existing users who had adapted to the old way.

That said, the situation where git cannot be found would generally occur only once. Repeated occurrences would only be possible if no_junction is set to true and scoop cleanup git is executed after updating Git, while continuing to use the same session without starting a new one.

Also, shims are about more than just the PATH. Some users have hardcoded them into their workflows or other environment variables.

We are actually facing a trade-off now: either ensure backward compatibility, or accept the inevitable inconvenience (breaking changes) to align its behavior with the non-portable version.

[SorYoshino]

We are actually facing a trade-off now: either ensure backward compatibility, or accept the inevitable inconvenience (breaking changes) to align its behavior with the non-portable version.

Yes, we cannot satisfy all users’ needs, as they each have their own reasons. I am more inclined to keep the manifest closer to the official installer’s behavior, at least when dealing with the bash.exe case.

[lxl66566]

thank you for your answers