I've gone ahead with pushing 50150, 50149, 50136, and 50134, because no one commented to the contrary on any of them. There have now been about 25 bugfixes (or configure updates) since 5.8.1.2-test, so we should probably do another test pre-release before going ahead with 5.9?
On Sat 30 Apr 2022, at 13:31, Bart Schaefer wrote:
> I've gone ahead with pushing 50150, 50149, 50136, and 50134, because
> no one commented to the contrary on any of them. There have now been
> about 25 bugfixes (or configure updates) since 5.8.1.2-test, so we
> should probably do another test pre-release before going ahead with
> 5.9?
Yeah i agree. I will try to do that tonight or tomorrow
dana
Bart Schaefer wrote on Sat, 30 Apr 2022 18:31 +00:00:
> I've gone ahead with pushing 50150, 50149, 50136, and 50134, because
> no one commented to the contrary on any of them. There have now been
> about 25 bugfixes (or configure updates) since 5.8.1.2-test, [...]
Looks like none of these have tests. It would be great if someone could
contribute these — either you if you have time, or if you don't, just
say so and someone else can jump in.
Which is to say: The fixes are very welcome; let's make sure they work
everywhere and don't regress, too :-)
Cheers,
Daniel
On Sun, May 1, 2022 at 7:53 AM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>
> Bart Schaefer wrote on Sat, 30 Apr 2022 18:31 +00:00:
> > I've gone ahead with pushing 50150, 50149, 50136, and 50134
>
> Looks like none of these have tests. It would be great if someone could
> contribute these — either you if you have time, or if you don't, just
> say so and someone else can jump in.
I'd appreciate it if you wrote the zstat test for 50150.
The tests for 50101, 50126, 50136, and 50149 should be
straightforward, I'll work on those.
I'm not sure how to write a test for 50134 because it requires
starting an interactive shell, waiting several seconds, then sending
it a SIGINT and discovering whether it exited immediately or N seconds
later.
Bart Schaefer wrote on Sun, May 01, 2022 at 09:50:14 -0700: > On Sun, May 1, 2022 at 7:53 AM Daniel Shahaf <d.s@daniel.shahaf.name> wrote: > > > > Bart Schaefer wrote on Sat, 30 Apr 2022 18:31 +00:00: > > > I've gone ahead with pushing 50150, 50149, 50136, and 50134 > > > > Looks like none of these have tests. It would be great if someone could > > contribute these — either you if you have time, or if you don't, just > > say so and someone else can jump in. > > I'd appreciate it if you wrote the zstat test for 50150. Sure. diff --git a/Test/D07multibyte.ztst b/Test/D07multibyte.ztst index cbd802f23..3c2dc082b 100644 --- a/Test/D07multibyte.ztst +++ b/Test/D07multibyte.ztst @@ -627,3 +627,14 @@ F:support character sets outside the portable 7-bit range. 0:locale gets restored when locale parameters go out of scope (regression test for 45772) >❯ >❯ + + # Subshell for zmodload isolation + ( + zmodload zsh/stat + touch 50150-é 50150-Ą + # Using +size solely in order to make it easier to write the expectations + zstat +size -nor -- 50150-* + ) +0:(workers/50150) zsh/stat with Unicode and metafication +>50150-Ą 0 +>50150-é 0 > The tests for 50101, 50126, 50136, and 50149 should be > straightforward, I'll work on those. Thank you. > I'm not sure how to write a test for 50134 because it requires > starting an interactive shell, waiting several seconds, then sending > it a SIGINT and discovering whether it exited immediately or N seconds > later. *nod* Daniel
On Sun, 2022-05-01 at 09:50 -0700, Bart Schaefer wrote:
> I'm not sure how to write a test for 50134 because it requires
> starting an interactive shell, waiting several seconds, then sending
> it a SIGINT and discovering whether it exited immediately or N seconds
> later.
Really interactive tests (beyond the level of simulated keystrokes or
delays) is really hard to test robustly. Certainly what we've got at
the moment doesn't cut the mustard. I had a quick look a while ago for
something that might be more robust but didn't see anything that looked
like it would work out of the box, and I certainly don't think any of us
are going to be doing it from scratch.
pws
[-- Attachment #1: Type: text/plain, Size: 984 bytes --] I included tests for all return values of sysread except "error in parameters". That includes a couple of Xfail tests for the $REPLY value. The doc says: ... The result of the read is stored in PARAM or REPLY if that is not given. ... If OUTFD is given, an attempt is made to write all the bytes just read to the file descriptor OUTFD. If this fails, ... the bytes read but not written are stored in the parameter named by PARAM if supplied .... If it was successful, COUNTVAR contains the full number of bytes transferred, as usual, and PARAM is not set. This doesn't really specify what happens when $REPLY (or the PARAM) already has a value before sysread is called. As currently implemented, the value (or unset-ness) is unchanged when the return status does not require that anything be assigned, so it's necessary to either carefully (un)set these parameters before calling sysread, or to test the return status before using them. [-- Attachment #2: test_sysread.txt --] [-- Type: text/plain, Size: 1952 bytes --] diff --git a/Test/V14system.ztst b/Test/V14system.ztst index ffdb730a4..81253324f 100644 --- a/Test/V14system.ztst +++ b/Test/V14system.ztst @@ -147,3 +147,69 @@ F:This timing test might fail due to process scheduling issues unrelated to zsh. 0:zsystem flock successful wait test, fractional seconds ?elapsed time seems OK F:This timing test might fail due to process scheduling issues unrelated to zsh. + + unset chars REPLY + print -n a few words | sysread -i 0 -c chars + ret=$? + print -- $chars x${REPLY}x + return ret +0:sysread default +>11 xa few wordsx + + unset chars REPLY + sysread -i 9 -c chars + ret=$? + print -- $chars x${REPLY}x + return ret +2:sysread read error +>-1 xx + + REPLY="say nothing" + sysread -i 9 -c chars + ret=$? + print -- $chars x${REPLY}x + return ret +2f:sysread read error +F:The value of $REPLY should be empty or unset when nothing is read? +>-1 xx + + unset chars REPLY + print -n a few words | sysread -i 0 -o 9 -c chars + ret=$? + print -- $chars x${REPLY}x + return ret +3:sysread write error +>11 xx + + sleep 3 | sysread -i 0 -t 1 +4:sysread timeout + + sysread -i 0 </dev/null +5:sysread end of file + + unset chars oration + print -n a few words | sysread -i 0 -o 9 -c chars oration + ret=$? + print $chars x${oration}x $REPLY + return ret +3:regression test: sysread write error with both -o and a parameter +>11 xa few wordsx + + unset chars oration + print a few words | sysread -i 0 -o 1 -c chars oration + ret=$? + print -- $chars x${oration}x $REPLY + return ret +0:regression test: sucessful sysread with both -o and a parameter +>a few words +>12 xx + + oration="do not say these words" + print a few words | sysread -i 0 -o 1 -c chars oration + ret=$? + print -- $chars x${oration}x $REPLY + return ret +0f:successful sysread with both -o and a parameter +F:The value of $oration should be empty or unset when everything is written? +>a few words +>12 xx
[-- Attachment #1: Type: text/plain, Size: 222 bytes --] These are short, so I kept them all in one patch. I was surprised that the existing Xfail test for temp file removal was still failing, so I added some explanatory comments. That one can probably be fixed after release. [-- Attachment #2: test_regress.txt --] [-- Type: text/plain, Size: 1476 bytes --] diff --git a/Test/D03procsubst.ztst b/Test/D03procsubst.ztst index 1e5cd9f6c..d68db35fa 100644 --- a/Test/D03procsubst.ztst +++ b/Test/D03procsubst.ztst @@ -167,5 +167,25 @@ print -rC1 -- $TMPPREFIX*(N) } 0f:external command with =(...) on LHS of pipeline cleans up its tempfiles +F:subshells including pipe LHS do not pass through zexit() # (Expected result: no output.) +# Confirm tempfile exists in the function, but not after exit + () { + local -x TMPPREFIX=$PWD/exit + $ZTST_testdir/../Src/zsh -fc ' + () { + print -rC1 -- $TMPPREFIX* + exit + } =(sleep 5) + ' + print -rC1 -- $TMPPREFIX*(N) + } +0:regression test: exit in shell function cleans up tempfiles +F:see preceding test +*>*.tmp/exit* + + print -u $ZTST_fd 'This test hangs the shell when it fails...' + true | false =(nosuchcommand$$) +1:regression test: race condition with pipe and procsubst +*?\(eval\):2: command not found: nosuchcommand* diff --git a/Test/E01options.ztst b/Test/E01options.ztst index 72749e6ab..b57b23557 100644 --- a/Test/E01options.ztst +++ b/Test/E01options.ztst @@ -752,6 +752,12 @@ >These are the contents of the file >These are the contents of the file +# Subshell to shield nullexec redirections + ( exec 3>&1 3>&2; print -u 3 some words ) +0:regression test: multios with nullexec +>some words +?some words + # tried this with other things, but not on its own, so much. unsetopt nomatch print with nonomatch: flooble*
> 2022/05/02 2:38, Daniel Shahaf <d.s@daniel.shahaf.name> wrote: > > --- a/Test/D07multibyte.ztst > +++ b/Test/D07multibyte.ztst (snip) > +0:(workers/50150) zsh/stat with Unicode and metafication > +>50150-Ą 0 > +>50150-é 0 On macOS this fails as: Testing multibyte with locale en_US.UTF-8 --- /tmp/zsh.ztst.90230/ztst.out 2022-05-02 10:11:21.000000000 +0900 +++ /tmp/zsh.ztst.90230/ztst.tout 2022-05-02 10:11:21.000000000 +0900 @@ -1,2 +1,2 @@ -50150-Ą 0 50150-é 0 +50150-Ą 0 Test ./D07multibyte.ztst failed: output differs from expected as shown above for: # Subshell for zmodload isolation ( zmodload zsh/stat touch 50150-é 50150-Ą # Using +size solely in order to make it easier to write the expectations zstat +size -nor -- 50150-* ) Was testing: (workers/50150) zsh/stat with Unicode and metafication It seems macOS uses collating order é < Ą (this may or may not a bug of macOS). If we need to test the two characters the simplest workaround would be: zstat +size -nor -- 50150-Ą zstat +size -nor -- 50150-é
On Sun, May 1, 2022 at 7:25 PM Jun T <takimoto-j@kba.biglobe.ne.jp> wrote: > > It seems macOS uses collating order é < Ą (this may or may not a bug of macOS). This is one of the potential reasons I didn't want to write this test. > If we need to test the two characters Unfortunately, the point is to test that two file names can be stat'd in one command. Try it this way? Has the added benefit of checking that we set the array elements correct. diff --git a/Test/D07multibyte.ztst b/Test/D07multibyte.ztst index 25634e502..e2e9a25ef 100644 --- a/Test/D07multibyte.ztst +++ b/Test/D07multibyte.ztst @@ -631,9 +631,12 @@ F:support character sets outside the portable 7-bit range. # Subshell for zmodload isolation ( zmodload zsh/stat + typeset -A sizes touch 50150-é 50150-Ą # Using +size solely in order to make it easier to write the expectations - zstat +size -nor -- 50150-* + zstat +size -A sizes -nor -- 50150-* + print -r -- 50150-Ą $sizes[50150-Ą] + print -r -- 50150-é $sizes[50150-é] ) 0:(workers/50150) zsh/stat with Unicode and metafication >50150-Ą 0
> 2022/05/02 12:10, Bart Schaefer <schaefer@brasslantern.com> wrote: > > Unfortunately, the point is to test that two file names can be stat'd > in one command. Sorry, I was not following the thread closely. > Try it this way? Has the added benefit of checking that we set the > array elements correct. It works fine, but: > 2022/05/02 11:24, Jun T <takimoto-j@kba.biglobe.ne.jp>wrote: > > If we need to test the two characters the simplest workaround would be: > > zstat +size -nor -- 50150-Ą > zstat +size -nor -- 50150-é I was stupid (this was not the simplest); the following works fine: zstat +size -nor -- 50150-Ą 50150-é But this does not have the additional "benefit" you mentioned. Please use either one as you like.
On one of my Mac, running macOS Monterey (11.1) on Apple M1 CPU, E01options fails as shown below (output with ZTST_verbose=2). The test passes on another Mac, macOS Mojave (10.14.6) with intel CPU. Anyone using macOS please test on your Mac to see it fails or not. Running test: regression test: multios with nullexec ZTST_test: expecting status: 0 Input: /tmp/zsh.ztst.51589/ztst.in, output: /tmp/zsh.ztst.51589/ztst.out, error: /tmp/zsh.ztst.51589/ztst.terr ZTST_execchunk: status 0 ZTST_test: test produced standard output: ZTST_test: and standard error: --- /tmp/zsh.ztst.51589/ztst.out 2022-05-02 13:24:56.000000000 +0900 +++ /tmp/zsh.ztst.51589/ztst.tout 2022-05-02 13:24:56.000000000 +0900 @@ -1 +0,0 @@ -some words Test ./E01options.ztst failed: output differs from expected as shown above for: ( exec 3>&1 3>&2; print -u 3 some words ) Error output: some words Was testing: regression test: multios with nullexec ./E01options.ztst: test failed. Note the two empty lines after "ZTST_test: test produced standard output:" and "ZTST_test: and standard error:". This means at this point ztsts.{tout,terr} are both empty. But after the diff output, it says: Error output: some words so at this point ztst.terr does have the correct data "some words"...? If I add a "sleep 1" after ( exec ... ): ( exec 3>&1 3>&2; print -u 3 some words ) sleep 1 then the test passes. But not sure whether this is a correct fix.
On Sun, May 1, 2022 at 10:00 PM Jun T <takimoto-j@kba.biglobe.ne.jp> wrote:>
>
> ( exec 3>&1 3>&2; print -u 3 some words )
> sleep 1
>
> then the test passes. But not sure whether this is a correct fix.
Try
( exec 3>&1 3>&2; print -u 3 some words; exec 3>&- )
??
> 2022/05/02 14:15, Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> Try
>
> ( exec 3>&1 3>&2; print -u 3 some words; exec 3>&- )
No, it does not work.
I also tried '1>&- 2>&- 3>&-' and '3>&- 1>&- 2>&-' with no success.
Bart Schaefer wrote on Mon, 02 May 2022 03:10 +00:00:
> On Sun, May 1, 2022 at 7:25 PM Jun T <takimoto-j@kba.biglobe.ne.jp> wrote:
>>
>> It seems macOS uses collating order é < Ą (this may or may not a bug of macOS).
>
> This is one of the potential reasons I didn't want to write this test.
>
Also one of the reasons I didn't push it as soon as I posted it.
Thanks for writing all the other tests and the patch for this one, Bart.
Daniel
> 2022/05/02 13:59, Jun T <takimoto-j@kba.biglobe.ne.jp> wrote:
>
> On one of my Mac, running macOS Monterey (11.1) on Apple M1 CPU,
> E01options fails as shown below (output with ZTST_verbose=2).
> The test passes on another Mac, macOS Mojave (10.14.6) with intel CPU.
Sorry, Monterey is ver 12, not 11.
I tested on a few other Macs.
The test fails only on Monterey (12), either Apple M1 or Intel.
It passes on Mojave (10.14), Catalina (10.15) and Big Sur (11).
On Mon, May 2, 2022 at 6:15 AM Jun. T <takimoto-j@kba.biglobe.ne.jp> wrote:
>
> I tested on a few other Macs.
> The test fails only on Monterey (12), either Apple M1 or Intel.
> It passes on Mojave (10.14), Catalina (10.15) and Big Sur (11).
OK, it's probably a process-switching thing then. The sleep might fix
it by assuring that the background multio job can flush its output
before the test job tries to read it. Could try writing directly to
temp files from the multio instead of using stdout and stderr, but
since those are directed to files anyway I'm not sure it would matter.