On Fri, Nov 13, 2020 at 4:32 PM Derrick Stolee <stolee@xxxxxxxxx> wrote: > On 11/13/2020 3:44 PM, Eric Sunshine wrote: > > On Fri, Nov 13, 2020 at 9:00 AM Derrick Stolee via GitGitGadget > > <gitgitgadget@xxxxxxxxx> wrote: > >> +test_expect_success MINGW 'start and stop Windows maintenance' ' > >> + write_script print-args <<-\EOF && > >> + echo $* >>args > >> + EOF > > > > Using `>>` here makes it harder to reason about the test than using > > `>` would, especially since `>>` seems to be unnecessary in this case. > > Since we execute the GIT_TEST_CRONTAB executable multiple times, we > need to use >> to log all three instances (and their order). Using ">args" > would only capture the final call for the weekly schedule. > > On macOS, there are as many as six calls (three bootouts, three bootstraps). Makes sense. Thanks. > >> + GIT_TEST_CRONTAB="/bin/sh print-args" git maintenance start && > > > > Is it a requirement on Windows to mention /bin/sh here? Specifically, > > I'm wondering why a simple ./print-args doesn't work. (It's especially > > unclear since write_script() is used heavily in the test suite and it > > seems to work well enough on Windows without specifying /bin/sh.) > > I landed on this after trying several attempts to get this to work, > including "$(pwd)/print-args" and I'm not sure why it doesn't work > in the Windows case. It is something to do with how I am executing > the subcommand from within Git. I'm pretty sure this idea of "mocking" > an executable through Git is relatively new, or at least rare Just for clarification... You mentioned in response to my [3/4] review that your accidentally-working write_script() only worked as expected on Mac but not on Windows. When you arrived at this solution of GIT_TEST_CRONTAB="/bin/sh ..." here, was that before or after you fixed write_script() to take the script body from stdin?
