On Mon, Apr 14, 2025 at 12:20:40PM -0700, Junio C Hamano wrote: > Patrick Steinhardt <ps@xxxxxx> writes: > > >> > Use "PERL_PATH" to execute Perl scripts, which makes them work on more > >> > esoteric systems like NixOS. > >> > >> I see in `t/perf/README` there's a mention of running `./aggregate.perl` > >> directly? Shall we inform the user to run that through their Perl as > >> well? > >> > >> - $ ./aggregate.perl . /path/to/other/git ./p0001-rev-list.sh > >> + $ perl ./aggregate.perl . /path/to/other/git ./p0001-rev-list.sh > > Good. > > >> > >> Or do we expect users to know what they are doing when they don't have > >> Perl installed at /usr/bin/perl? > > > > Another solution could be to switch the shebang to `#!/usr/bin/env > > perl`. We also do this for "t/chainlint.pl". > > When you do not have perl installed anywhere, how does this fail? I > think you would get > > $ ./aggregate.perl ... > /usr/bin/env: 'perl': No such file or directory > > and compared to that, > > $ perl ./aggregate.perl ... > bash: perl: command not found > > I think it makes it slightly more obvious to those who lack perl on > their $PATH what is going wrong to explicitly tell them to run > "perl" like Toon's suggestion above (primarily because use of > /usr/bin/env is not obvious to those who are told to run > ./aggregate.perl script). The counterargument is that `#!/usr/bin/env perl` works on systems where Perl is in PATH, but in a non-standard location. So isn't it preferable to make things Just Work(TM) on such systems instead of giving slightly better error messages on systems where it wouldn't work anyway because Perl is not available? I certainly think so, but if you or others feel strongly I'll adapt. Patrick
