After a moment's thought I decided to run ape/psh before building git. If so then, sh will be found from the directories named in PATH because it is mounted onto /bin. 2020年8月7日(金) 2:30 Junio C Hamano <gitster@xxxxxxxxx>: > > Eric Sunshine <sunshine@xxxxxxxxxxxxxx> writes: > > > On Wed, Aug 5, 2020 at 10:14 PM brian m. carlson > > <sandals@xxxxxxxxxxxxxxxxxxxx> wrote: > >> On 2020-08-06 at 01:05:01, lufia via GitGitGadget wrote: > >> > In the not POSIX environment, like Plan 9, sh might not be looked up > >> > in the directories named by the $PATH. > >> > >> I think Git's editor handling assumes that sh is somewhere in the PATH, > >> so it might be fine for us to just ask the user to adjust PATH > >> appropriately before running make. I don't have a strong preference; if > >> this works on a standard Unix machine, which it looks like it should > >> (although I haven't tested), I'm fine with it. > > > > This does, however, have a bit of a chicken-and-egg feel to it. The > > results of the "uname_FOO" assignments in config.mak.uname are > > consulted later in the file to _assign_ a value to SHELL_PATH on a > > number of platforms. So, making the "uname_FOO" assignments themselves > > depend upon SHELL_PATH is rather circular and confusing. > > Is that just being circular and confusing, or does it produce an > incorrect result depending on the circumstances? We would end up > special casing SHELL_PATH (e.g. exclude it from the variables that > are set based on uname), which I would want to avoid, as I would > suspect that there will be even more variables that need similar > treatment. > > This does have a bad smell. Even on a not-so-posix Windows, we do > not use such a hack. >
