Skip to content

Fix up checks in Makefile and make them portable #1661

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 18 commits into from
Sep 15, 2023
Merged
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Prevent buggy interaction between MinGW and WSL
This changes the hashbangs in Makefile helper scripts to be static.

Often, "#!/usr/bin/env bash" is a better hashbang for bash scripts
than "#!/bin/bash", because it automatically works on Unix-like
systems that are not GNU/Linux and do not have bash in /bin, but
on which it has been installed in another $PATH directory, such as
/usr/local/bin. (It can also be helpful on macOS, where /bin/bash
is usually an old version of bash, while a package manager such as
brew may have been used to install a newer version elsewhere.)

Windows systems with WSL installed often have a deprecated bash.exe
in the System32 directory that runs commands and scripts inside an
installed WSL system. (wsl.exe should be used instead.) Anytime
that bash is used due to a "#!/usr/bin/env bash" hashbang, it is
wrong, because that only happens if the caller is some Unix-style
script running natively or otherwise outside WSL.

Normally this is not a reason to prefer a "#!/bin/bash" hashbang,
because normally any environment in which one can run a script in a
way that determines its interpreter from its hashbang is an
environment in which a native (or otherwise appropriate) bash
precedes the System32 bash in a PATH search. However, MinGW make,
a popular make implementation used on Windows, is an exception.

The goal of this change is not to sacrifice support for some
Unix-like systems to better support Windows, which wouldn't
necessarily be justified. Rather, this is to avoid extremely
confusing wrong behavior that in some cases would have bizarre
effects that are very hard to detect. I discovered this problem
because the VIRTUAL_ENV variable was not inheried by the bash
interpreter (because it was, fortunately, not passed through to
WSL). But if "python3 -m build" finds a global "build" package,
things might get much further before any problem is noticed.
  • Loading branch information
EliahKagan committed Sep 14, 2023
commit 729372f6f87639f0c4d8211ee7d173100117a257
2 changes: 1 addition & 1 deletion build-release.sh
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
#!/usr/bin/env bash
#!/bin/bash
#
# This script builds a release. If run in a venv, it auto-installs its tools.
# You may want to run "make release" instead of running this script directly.
Expand Down
2 changes: 1 addition & 1 deletion check-version.sh
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
#!/usr/bin/env bash
#!/bin/bash
#
# This script checks if we are in a consistent state to build a new release.
# See the release instructions in README.md for the steps to make this pass.
Expand Down