PATCH: test output to terminal dehackery

PATCH: test output to terminal dehackery

[Peter Stephenson]

We now have the technology to open a file descriptor for test input and
terminal output without using up one of the standard shell ones.
The {fd}<redir> syntax opens up an unused fd from 10 on.

Index: Test/A01grammar.ztst
===================================================================
RCS file: /cvsroot/zsh/zsh/Test/A01grammar.ztst,v
retrieving revision 1.14
diff -u -r1.14 A01grammar.ztst
--- Test/A01grammar.ztst	8 May 2007 10:02:59 -0000	1.14
+++ Test/A01grammar.ztst	29 May 2007 14:42:22 -0000
@@ -452,7 +452,7 @@
 >chrysanthemum contains an e
 >Zanzibar either begins with a or an upper case letter
 
-  print 'This test hangs the shell when it fails...' >&8
+  print -u $ZTST_fd 'This test hangs the shell when it fails...'
   name=0
 # The number 4375 here is chosen to produce more than 16384 bytes of output
   while (( name < 4375 )); do
Index: Test/C03traps.ztst
===================================================================
RCS file: /cvsroot/zsh/zsh/Test/C03traps.ztst,v
retrieving revision 1.10
diff -u -r1.10 C03traps.ztst
--- Test/C03traps.ztst	12 Jan 2007 23:10:20 -0000	1.10
+++ Test/C03traps.ztst	29 May 2007 14:42:22 -0000
@@ -122,7 +122,7 @@
 # least the full two seconds to make sure we have got the output from the
 # execution of the trap.
 
-  print 'This test takes at least three seconds...' >&8
+  print -u $ZTST_fd 'This test takes at least three seconds...'
   fn1() {
     trap 'print TERM1' TERM
     fn2() { trap 'print TERM2; return 1' TERM; sleep 2; }
@@ -135,7 +135,7 @@
 0: Nested `trap ... TERM', triggered on inner loop
 >TERM2
 
-  print 'This test, too, takes at least three seconds...' >&8
+  print -u $ZTST_fd 'This test, too, takes at least three seconds...'
   fn1() {
     trap 'print TERM1; return 1' TERM
     fn2() { trap 'print TERM2; return 1' TERM; }
@@ -253,7 +253,7 @@
 >Exiting, attempt 2
 >Running exit trap
 
-  print Another test that takes three seconds >&8
+  print -u $ZTST_fd Another test that takes three seconds
   gotsig=0
   signal_handler() {
    echo "parent received signal"
Index: Test/D07multibyte.ztst
===================================================================
RCS file: /cvsroot/zsh/zsh/Test/D07multibyte.ztst,v
retrieving revision 1.16
diff -u -r1.16 D07multibyte.ztst
--- Test/D07multibyte.ztst	15 Apr 2007 21:42:43 -0000	1.16
+++ Test/D07multibyte.ztst	29 May 2007 14:42:23 -0000
@@ -16,7 +16,7 @@
   if [[ -z $mb_ok ]]; then
     ZTST_unimplemented="no UTF-8 locale or multibyte mode is not implemented"
   else
-    print Testing multibyte with locale $LANG >&8
+    print -u $ZTST_fd Testing multibyte with locale $LANG
   fi
 
 %test
Index: Test/E01options.ztst
===================================================================
RCS file: /cvsroot/zsh/zsh/Test/E01options.ztst,v
retrieving revision 1.19
diff -u -r1.19 E01options.ztst
--- Test/E01options.ztst	23 May 2007 11:44:49 -0000	1.19
+++ Test/E01options.ztst	29 May 2007 14:42:24 -0000
@@ -668,7 +668,7 @@
 >hello
 
 # This tests for another race in multios.
-  print 'This test hangs the shell when it fails...' >&8
+  print -u $ZTST_fd 'This test hangs the shell when it fails...'
   setopt multios
   echo These are the contents of the file >multio_race.out
   multio_race_fn() { cat; }
Index: Test/ztst.zsh
===================================================================
RCS file: /cvsroot/zsh/zsh/Test/ztst.zsh,v
retrieving revision 1.26
diff -u -r1.26 ztst.zsh
--- Test/ztst.zsh	28 Nov 2006 22:09:00 -0000	1.26
+++ Test/ztst.zsh	29 May 2007 14:42:24 -0000
@@ -147,10 +147,14 @@
 ZTST_verbose() {
   local lev=$1
   shift
-  [[ -n $ZTST_verbose && $ZTST_verbose -ge $lev ]] && print -r -- $* >&8
+  if [[ -n $ZTST_verbose && $ZTST_verbose -ge $lev ]]; then
+    print -r pu $ZTST_fd -- $*
+  fi
 }
 ZTST_hashmark() {
-  [[ ZTST_verbose -le 0 && -t 8 ]] && print -nu8 ${(pl:SECONDS::\#::\#\r:)}
+  if [[ ZTST_verbose -le 0 && -t $ZTST_fd ]]; then
+    print -n -u$ZTST_fd -- ${(pl:SECONDS::\#::\#\r:)}
+  fi
   (( SECONDS > COLUMNS+1 && (SECONDS -= COLUMNS) ))
 }
 
@@ -159,8 +163,8 @@
   exit 1
 fi
 
-exec 8>&1
-exec 9<$ZTST_testname
+exec {ZTST_fd}>&1
+exec {ZTST_input}<$ZTST_testname
 
 # The current line read from the test file.
 ZTST_curline=''
@@ -172,7 +176,7 @@
 ZTST_getline() {
   local IFS=
   while true; do
-    read -r ZTST_curline <&9 || return 1
+    read -u $ZTST_input -r ZTST_curline || return 1
     [[ $ZTST_curline == \#* ]] || return 0
   done
 }


-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


To access the latest news from CSR copy this link into a web browser:  http://www.csr.com/email_sig.php

To get further information regarding CSR, please visit our Investor Relations page at http://ir.csr.com/csr/about/overview

Re: PATCH: test output to terminal dehackery

[Stephane Chazelas]

On Tue, May 29, 2007 at 03:43:40PM +0100, Peter Stephenson wrote:
[...]
> diff -u -r1.26 ztst.zsh
> --- Test/ztst.zsh	28 Nov 2006 22:09:00 -0000	1.26
> +++ Test/ztst.zsh	29 May 2007 14:42:24 -0000
> @@ -147,10 +147,14 @@
>  ZTST_verbose() {
>    local lev=$1
>    shift
> -  [[ -n $ZTST_verbose && $ZTST_verbose -ge $lev ]] && print -r -- $* >&8
> +  if [[ -n $ZTST_verbose && $ZTST_verbose -ge $lev ]]; then
> +    print -r pu $ZTST_fd -- $*
[...]

Hi Peter,

The above looks like a typo. That p should have been a "-"
shouldn't it?

-- 
Stéphane

Re: PATCH: test output to terminal dehackery

[Bart Schaefer]

On May 29,  3:43pm, Peter Stephenson wrote:
}
} We now have the technology to open a file descriptor for test input and
} terminal output without using up one of the standard shell ones.
} The {fd}<redir> syntax opens up an unused fd from 10 on.

Hrm.  I'm ambivalent about this patch.  The {fd}< syntax is one of the
things that gets tested for correctness quite a bit later on.  If it
doesn't work properly here, could the whole test suite fail?

That is, I'm wondering if the implementation of the test suite should
restrict itself to the most basic shell operations possible and only
the tests themselves employ extended functionality.  There's a reason
e.g. we don't attempt completion tests until after we've tested module
loading ...

However, I won't make a fuss if no one else cares.

Re: PATCH: test output to terminal dehackery

[Peter Stephenson]

Bart Schaefer wrote:
> On May 29,  3:43pm, Peter Stephenson wrote:
> }
> } We now have the technology to open a file descriptor for test input and
> } terminal output without using up one of the standard shell ones.
> } The {fd}<redir> syntax opens up an unused fd from 10 on.
> 
> Hrm.  I'm ambivalent about this patch.  The {fd}< syntax is one of the
> things that gets tested for correctness quite a bit later on.  If it
> doesn't work properly here, could the whole test suite fail?
> 
> That is, I'm wondering if the implementation of the test suite should
> restrict itself to the most basic shell operations possible and only
> the tests themselves employ extended functionality.

I don't really believe in the division between basic and extended
functionality, except as regards add-ons; if the shell's broken it needs
fixing.  You're correct that the new syntax isn't used as much so it's
more likely it would get broken without anyone noticing.  I don't see
any implication beyond needing to fix that before running other
tests, however; that can in principle happen with anything.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


To access the latest news from CSR copy this link into a web browser:  http://www.csr.com/email_sig.php

To get further information regarding CSR, please visit our Investor Relations page at http://ir.csr.com/csr/about/overview

Re: PATCH: test output to terminal dehackery

[Bart Schaefer]

On May 30, 10:49am, Peter Stephenson wrote:
}
} > That is, I'm wondering if the implementation of the test suite should
} > restrict itself to the most basic shell operations possible and only
} > the tests themselves employ extended functionality.
} 
} I don't really believe in the division between basic and extended
} functionality, except as regards add-ons; if the shell's broken it needs
} fixing.

OK, let me restate my position slightly.

The test suite should restrict itself only to the constructs that are
least likely to be affected by operating system and compiler portability
issues, so that it isn't necessary for a person building and testing on
a brand-new or otherwise unusual platform to fix an obscure or difficult
problem based on an unknown failure in a very complex piece of shell code
when there's a minimal example buried somewhere in the suite that might
immediately reveal the actual problem.

The test suite isn't just about you or me finding something we broke in
development.

Re: PATCH: test output to terminal dehackery

[Peter Stephenson]

Bart Schaefer wrote:
> The test suite should restrict itself only to the constructs that are
> least likely to be affected by operating system and compiler portability
> issues, so that it isn't necessary for a person building and testing on
> a brand-new or otherwise unusual platform to fix an obscure or difficult
> problem based on an unknown failure in a very complex piece of shell code
> when there's a minimal example buried somewhere in the suite that might
> immediately reveal the actual problem.
> 
> The test suite isn't just about you or me finding something we broke in
> development.

That's fair enough, but I don't think a change in the redirection
syntax qualifies as something likely to produce a portability problem.
The underlying features used are the same; the addition is an internal
shell parameter assignment (which had also better work).  Unless you
think using file descriptors over 10 is likely to be problematic?  But
the shell has used those internally for a long time.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


To access the latest news from CSR copy this link into a web browser:  http://www.csr.com/email_sig.php

To get further information regarding CSR, please visit our Investor Relations page at http://ir.csr.com/csr/about/overview