Re: Testing interactive features (Re: capturing output of !! not working)

[Mikael Magnusson <mikachu@xxxxxxxxx>]

On Tue, Mar 24, 2015 at 5:09 PM, Bart Schaefer
<schaefer@xxxxxxxxxxxxxxxx> wrote:
> On Mar 23,  9:45pm, Bart Schaefer wrote:
> } Subject: Re: Testing interactive features (Re: capturing output of !! not
> }
> } } ... a patch to comptest for the Test/X01* failure with no TTY.
> } }
> } } -    (( first++ )) && read -t 0.011 -k 1 < /dev/null
> } } +    (( first++ )) && read -t 0.011 -u 0 -k 1 < /dev/null
> }
> } Well, that shuts up the error message, but it also causes the 0.011
> } second timeout to be ignored.  The test still succeeds for me, but
> } should get a more thorough examination.
>
> If the real point is to sleep for 0.11 seconds, input needs to be
> redirected from somewhere that doesn't instantly return EOF.  That
> means tty or an open pipe.  Can anyone think of a less silly-looking
> way to do that, than the below?
>
> (The -u 0 -k 1 are probably redundant now.)
>
> First hunk is for a thinko in my %prep.
>
> diff --git a/Test/W01history.ztst b/Test/W01history.ztst
> index 2492c41..3a64530 100644
> --- a/Test/W01history.ztst
> +++ b/Test/W01history.ztst
> @@ -2,7 +2,7 @@
>
>  %prep
>
> -  [[ -t 0 ]] && print -u $ZTST_fd History tests write to /dev/tty
> +  if [[ -t 0 ]]; then print -u $ZTST_fd History tests write to /dev/tty; fi
>
>  %test
>
> diff --git a/Test/comptest b/Test/comptest
> index ef84217..20a3a5b 100644
> --- a/Test/comptest
> +++ b/Test/comptest
> @@ -164,7 +164,7 @@ zletest () {
>    for input; do
>      # zpty_flush Before zletest
>      # sleep for $KEYTIMEOUT
> -    (( first++ )) && read -t 0.011 -u 0 -k 1 < /dev/null
> +    (( first++ )) && { sleep 2 & } | read -t 0.011 -u 0 -k 1
>      zpty -n -w zsh "$input"
>    done
>    zpty -n -w zsh $'\C-X'

This patch causes the test suite to fail on a shell account I have
that has ulimit -l 50 in effect. X02 does about 90 tests, each of them
starts that sleep which stays around forever, and then real tests
can't fork. I don't know if we care about this situation or not, but
just thought I'd let you know. If there's an easy way to kill that
sleep synchronously on the next line, that'd be nice...

I was trying to do just that with something like
    { { (( first++ )) && { sleep 2 & echo $! } | read -t 0.011 -u 0 -k
1 } 9>&1 } | read
    (( REPLY )) && kill $REPLY
but the kill was failing every time, then I noticed this also seems to fix it,
    { (( first++ )) && { sleep 2 & } | read -t 0.011 -u 0 -k 1 } | :
and I am not sure why. It doesn't introduce any delays, so it's not
waiting for the sleep to finish; is it killing them automatically
because it's in a subshell? That's nice if so, but seems unlikely.

-- 
Mikael Magnusson