Instead of running bazel as a subprocess of bazelisk, replace bazelisk with bazel in the same process (in the case when bazelisk is only being used to invoke bazel once and then exit, as opposed to invoking bazel multiple times or post-processing output from bazel). This eliminates several classes of issues.
A couple concrete examples:
shells' segfault detection often does not fire on subprocesses, so doing bazel run //:something_that_segfaults will not cause bash to display that the process segfaulted if bazelisk subprocesses to bazel, but it does if bazelisk execs bazel.
terminal emulators that display the name of the running process currently display bazel, even once bazel run has execd the binary it built, since the running top-level process is still bazelisk; they should display the name of the binary, and they do after this change
syscall.Exec is not supported on windows, so this only applies to linux and macos.
Instead of running bazel as a subprocess of bazelisk, replace bazelisk with bazel in the same process (in the case when bazelisk is only being used to invoke bazel once and then exit, as opposed to invoking bazel multiple times or post-processing output from bazel). This eliminates several classes of issues.
A couple concrete examples:
bazel run //:something_that_segfaultswill not cause bash to display that the process segfaulted if bazelisk subprocesses to bazel, but it does if bazeliskexecs bazel.bazel, even oncebazel runhasexecd the binary it built, since the running top-level process is still bazelisk; they should display the name of the binary, and they do after this changesyscall.Execis not supported on windows, so this only applies to linux and macos.