On Sunday, July 14, 2024 2:16 PM, brian m. carlson wrote: >To: Junio C Hamano <gitster@xxxxxxxxx> >Cc: rsbecker@xxxxxxxxxxxxx; git@xxxxxxxxxxxxxxx >Subject: Re: [Test Breakage 2.46.0-rc0] Test t0021.35 fails on NonStop > >On 2024-07-14 at 17:00:12, Junio C Hamano wrote: >> <rsbecker@xxxxxxxxxxxxx> writes: >> >> > This looks like a different between ksh and bash. Under bash, the >> > test works. I can live with that but will have to force bash to be >> > used as the shebang #!/bin/sh defaults to ksh on this box. >> >> It turns out that the version of ksh I used in my description does not >> seem to grok "local" at all. I vaguely recall that we've written off >> various hobbist reimplementation of ksh as unusable enough, but this >> one is ksh93 direct from AT&T Research. >> >> I guess when we said "as long as we limit our use to a simple 'this >> variable has visibility limited to the function and its children' >> and nothing else, it is portable enough across practically everybody >> we care about", we have written off the real ksh, too. >> >> In the meantime, we may want to document this in a more prominent way. >> Perhaps like so: >> >> -------- >8 --------------- >8 --------------- >8 -------- >> Subject: doc: guide to use of "local" shell language construct >> >> The scripted Porcelain commands do not allow use of "local" because it >> is not universally supported, but we use it liberally in our test >> scripts, which means some POSIX compliant shells (like "ksh93") can >> not be used to run our tests. >> >> Document the status quo, and hint that we might want to change the >> situation in the fiture. > >I don't think this is the right approach. Every version of ksh _except_ AT&T ksh >works just fine here. pdksh, mksh, lksh, OpenBSD's ksh (which is also its /bin/sh) >work fine, as do bash, dash, FreeBSD's sh (ash), Busybox's sh (also ash), and zsh >(when run in sh mode with 5.9 or newer). AT&T ksh is considering adding local in a >newer version for this reason. > >Literally only AT&T ksh is not supported here, and so anyone can set SHELL_PATH to >any suitable shell. I don't think it's useful to get rid of local when there are a variety >of acceptable and portable options. We can add NonStop's ksh to the list of not supported. I'm using TEST_SHELL_PATH while running make all in the t directory. Test passes when I use bash. For some reason (maybe GNUMake 4.1, which is what I have in my POSIX environment, I don't get TEST_SHELL_PATH passed down from the outer Makefile, but I can work with that. t0021 is now passing in my current CI stream using bash 5.0.18. --Randall
