Running tests without installing Zsh

Running tests without installing Zsh

[Andrej Borsenkow]

If Zsh is compiled with dynamic loading, it is near to impossible to run
tests without installing Zsh (at least, Zsh modules and, probably,
functions). Even setting module_path to $srcdir/Src/*(/) does not help,
because Zsh loads modules as zsh/<module> - and we do not have zsh
subdirectories in this case.

One possibility is to use separate directory for compiled binaries. Bin/zsh
for zsh itself and Bin/Modules for modules with the same structure as in
installation directory. Then in ztst.zsh (or, possibly, as parameter) use

module_path=($PWD/../Bin/Modules)

and in Test/Makefile

check:
	$PWD/../Bin/zsh -f ztst.zsh

Of course, if any test runs as interactive, it will pick up wrong module
anyway as we cannot override module_path at Zsh startup.

Is any module loaded at non-interactive shell startup?

/andrej

PATCH: Re: Running tests without installing Zsh

[Bart Schaefer]

On Mar 3,  2:43pm, Andrej Borsenkow wrote:
} Subject: Running tests without installing Zsh
}
} If Zsh is compiled with dynamic loading, it is near to impossible to run
} tests without installing Zsh (at least, Zsh modules and, probably,
} functions).

I'd been noticing that.  The completion test in particular requires both
functions and dynamic loading; zregexparse needs modules.  Otherwise the
tests have been of purely builtin functionality.

Maybe we could encode this in the test-numbering scheme somehow ...

} Even setting module_path to $srcdir/Src/*(/) does not help,
} because Zsh loads modules as zsh/<module> - and we do not have zsh
} subdirectories in this case.

We can deal with that, I think.

} Of course, if any test runs as interactive, it will pick up wrong module
} anyway as we cannot override module_path at Zsh startup.

That's fixable, too.  The one thing we can't fix is that modules may be
autoloaded if the system has an /etc/zshenv file.  

} Is any module loaded at non-interactive shell startup?

Only the built-in pseudo-modules, unless /etc/zshenv causes one to be
loaded.

Here's a patch.  BTW, I noticed a number of inconsequential typos in
comptest, but didn't bother to fix any of them.  It would be nice if
comptest displayed some sort of progress indication, the way the traps
tests do; at one point while trying the changes below one of the zsh
running inside zpty exited prematurely, and the result was that comptest
locked up and had to be killed.  I didn't know how long to wait before
giving up on it.

Index: Test/53completion.ztst
===================================================================
@@ -3,6 +3,7 @@
 %prep
   zmodload -i zsh/zpty
 
+  export ZTST_testdir ZTST_srcdir
   comptest () { $ZTST_testdir/../Src/zsh -f $ZTST_srcdir/comptest -z $ZTST_testdir/../Src/zsh -d $ZTST_testdir/compdump.tmp "$@" }
 
   mkdir comp.tmp
Index: Test/Makefile.in
===================================================================
@@ -41,9 +41,14 @@
 # ========== DEPENDENCIES FOR TESTING ==========
 
 check test:
+	if test -n "$(DLLD)"; then \
+	  cd $(dir_top) && \
+	  $(MAKE) MODDIR=`pwd`/$(subdir)/Modules install.modules > /dev/null; \
+	fi
 	for f in $(sdir)/*.ztst; do \
-	  ../Src/zsh -f $(sdir)/ztst.zsh $$f; \
+	  $(dir_top)/Src/zsh -f $(sdir)/ztst.zsh $$f; \
 	done
+	rm -rf Modules
 
 # ========== DEPENDENCIES FOR CLEANUP ==========
 
Index: Test/comptest
===================================================================
@@ -1,8 +1,12 @@
 #!/usr/local/bin/zsh -f
 
+[[ -d $ZTST_testdir/Modules/zsh ]] && module_path=( $ZTST_testdir/Modules )
+
 zmodload -i zsh/zpty
 setopt extendedglob
 
+fpath=( ${ZTST_srcdir:h}/(Completion|Functions)/*~*/CVS(/) )
+
 debug=
 dump=(-D)
 code=
@@ -24,6 +28,8 @@
 tmp=/tmp/comptest.$$
 
 cat <<End >$tmp
+module_path=( $module_path )
+fpath=( $fpath )
 stty columns 80 rows 24
 LISTMAX=10000000
 ZLS_COLORS='no=<NO>:fi=<FI>:di=<DI>:ln=<LN>:pi=<PI>:so=<SO>:bd=<BD>:cd=<CD>:ex=<EX>:mi=<MI>:tc=<TC>:sp=<SP>:lc=<LC>:ec=<EC>\n:rc=<RC>'
Index: Test/ztst.zsh
===================================================================
@@ -22,6 +22,10 @@
 # still not be good enough.  Maybe we should trick it somehow.
 emulate -R zsh
 
+# Set the module load path to correspond to this build of zsh.
+# This Modules directory should have been created by "make check".
+[[ -d Modules/zsh ]] && module_path=( $PWD/Modules )
+
 # We need to be able to save and restore the options used in the test.
 # We use the $options variable of the parameter module for this.
 zmodload -i zsh/parameter
@@ -46,6 +50,9 @@
 # The source directory is not necessarily the current directory
 ZTST_srcdir=${0%/*}
 [[ $ZTST_srcdir = /* ]] || ZTST_srcdir="$ZTST_testdir/$ZTST_srcdir"
+
+# Set the function autoload paths to correspond to this build of zsh.
+fpath=( ${ZTST_srcdir:h}/(Completion|Functions)/*~*/CVS(/) )
 
 : ${TMPPREFIX:=/tmp/zsh}
 # Temporary files for redirection inside tests.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Blocking zpty once again

[Andrej Borsenkow]

 at one point while trying the changes below one of the zsh
> running inside zpty exited prematurely, and the result was that comptest
> locked up and had to be killed.  I didn't know how long to wait before
> giving up on it.
>

Yes. Playing with zpty I found, that there is no way to kill zpty read. I
tried

zpty -r cmd foo pat

with wrong (as it turned out) pattern. It was in interactive shell, and
neither of ^C, ^\, ^Z helped.

Exactly for this reason we need either read with timeout or general purpose
select (nice to have independently of zpty).

Also, I'm not sure what happens when child exits. I tried something simple
as

zsh cat cat /etc/profile
zsh -r cat

but got nothing. Looks like pty was flushed in this case. Child did not
exist anymore, but zsh still insisted on valid `cat' handle. I'd expect it
to detect dead pty - not sure, how to do it in general case.

/andrej

Re: PATCH: Re: Running tests without installing Zsh

[Zefram]

Bart Schaefer wrote:
>That's fixable, too.  The one thing we can't fix is that modules may be
>autoloaded if the system has an /etc/zshenv file.  

How about a command-line option to disable processing of the global
rc files?

More radical idea: how about making --disable-z{sh{env,rc},profile,log{in,out}}
the default?  It is very rare that any of these files is genuinely
required (I've seen approximately one case where an /etc/zshenv was
justified), and they are very frequently misused.  It seems reasonable
to require the unusual systems that actually need this feature to
explicitly enable it at compile time, and it would mean that the great
mass of unthinking admins won't be able to screw up their users' shell
environments.

-zefram