@fweikert, could you please take a look at it?

@valco1994 why only exec when we find a run in the arg list (presumably indicating you're doing bazel run ...)? Why not exec always like I did in #566 (except when bazelisk itself has more work to do after)?

This seems especially confusing if I'm reading correctly and this will exec if you do like bazel --config run build or something, which is totally valid I think (equivalent to bazel --config=run build)

@aaron-skydio, I missed your pull request, and found it only when my pull request was already merged. So, I didn't consider making exec as often as possible, as was proposed by you in #566.

Considering the motivation, I wanted to fix issues reported by users - #512 and #556 - and in both cases, problematic scenarios were related to bazelisk run. Also, bazelisk is supposed to be a transparent wrapper around Bazel, and Bazel uses exec in the case of bazel run. It was impossible to rely on this behaviour before, when bazelisk was used, and it's possible now after my changes.

I have nothing against using exec more broadly, but probably it's worth thinking about scenarios which it can improve. Because we can't use exec always and must support both approaches anyway.

Yeah, I think the best (and easiest) way to be a transparent wrapper in general is with exec, regardless of whether bazel then again calls exec on a binary it's built or not. Agree it's most important/noticeable with bazel run though, and I think all of the issues we've hit related to this are with bazel run? Although regular behavior of bazel itself (e.g. during a build) on SIGQUIT is also weird when bazelisk is in the way and doesn't exec

Your reasoning is really well-founded, and an example with --config run is very representative. I like the idea and would be glad if it was implemented.

But I'm not a maintainer of this project, just a regular contributor.

@fweikert, what do you think about the idea of @aaron-skydio?