PATCH: minor module tweak

PATCH: minor module tweak

[Peter Stephenson]

While playing about with zmodload I noted that a failed zmodload
doesn't flag an error, so you can use it as a test for module
availability.  I've interpreted this as a feature and documented it.

I've changed some zerr()'s that were saving errflag to zwarn()'s that
don't need to.  I think this is just because we didn't always have the
complete set of interfaces.

Index: Doc/Zsh/builtins.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/builtins.yo,v
retrieving revision 1.90
diff -u -r1.90 builtins.yo
--- Doc/Zsh/builtins.yo	19 Dec 2006 10:35:55 -0000	1.90
+++ Doc/Zsh/builtins.yo	23 Mar 2007 14:18:00 -0000
@@ -1864,7 +1864,13 @@
 a standard suffix, usually `tt(.so)' (`tt(.sl)' on HPUX).
 If the module to be loaded is
 already loaded and the tt(-i) option is given, the duplicate module is
-ignored.  Otherwise tt(zmodload) prints an error message.
+ignored.  Otherwise tt(zmodload) prints an error message and returns
+a non-zero status.  The current code block is not aborted unless
+tt(zmodload) detects an inconsistency, such as an invalid module name
+or circular dependency list.  Hence `tt(zmodload -i) var(module)
+tt(2>/dev/null)' is sufficient to test whether a module is available.
+If it is available, the module is loaded if necessary, while if it
+is not available, non-zero status is silently returned.
 
 The var(name)d module is searched for in the same way a command is, using
 tt($module_path) instead of tt($path).  However, the path search is
Index: Src/module.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/module.c,v
retrieving revision 1.24
diff -u -r1.24 module.c
--- Src/module.c	6 Feb 2007 21:47:54 -0000	1.24
+++ Src/module.c	23 Mar 2007 14:18:00 -0000
@@ -439,11 +439,8 @@
     void *ret;
 
     ret = try_load_module(name);
-    if (!ret && !silent) {
-	int waserr = errflag;
-	zerr("failed to load module: %s", name);
-	errflag = waserr;
-    }
+    if (!ret && !silent)
+	zwarn("failed to load module: %s", name);
     return ret;
 }
 
@@ -454,11 +451,8 @@
 static void *
 do_load_module(char const *name, int silent)
 {
-    int waserr = errflag;
-
     if (!silent)
-	zerr("failed to load module: %s", name);
-    errflag = waserr;
+	zwarn("failed to load module: %s", name);
 
     return NULL;
 }

-- 
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: minor module tweak

[Bart Schaefer]

On Mar 23,  2:18pm, Peter Stephenson wrote:
}
} While playing about with zmodload I noted that a failed zmodload
} doesn't flag an error, so you can use it as a test for module
} availability.  I've interpreted this as a feature and documented it.

It's certainly been used this way ever since the -i flag was added;
e.g. in zfinit:  zmodload -i zsh/net/tcp || return 1

So it's fine that you documented this, but I think it was implicit all
along in the phrase "prints an error message and returns a non-zero
status."  (If it were going to abort the code block, it couldn't return
a status, could it?)

There are a few places in Functions/**/*(.) where the "|| return 1"
could helpfully to be appended to a "zmodload -i" that currently just
assumes it will succeed.

Re: PATCH: minor module tweak

[Peter Stephenson]

Bart Schaefer wrote:
> So it's fine that you documented this, but I think it was implicit all
> along in the phrase "prints an error message and returns a non-zero
> status."  (If it were going to abort the code block, it couldn't return
> a status, could it?)

Yeahburrid didn't say that before...

-ignored.  Otherwise tt(zmodload) prints an error message.
+ignored.  Otherwise tt(zmodload) prints an error message and returns
+a non-zero status.  The current code block is not aborted unless
+tt(zmodload) detects an inconsistency, such as an invalid module name
+or circular dependency list.  Hence `tt(zmodload -i) var(module)
+tt(2>/dev/null)' is sufficient to test whether a module is available.
+If it is available, the module is loaded if necessary, while if it
+is not available, non-zero status is silently returned.

You're right that I've been a bit wordier in the change then necessary,
but I think it's useful to say that the code block is aborted on an
inconsistency (though I could have phrased that the other way round, so
the nitpicking version might read "If tt(zmodload) detects an
inconsistency ... the current code block is aborted") and the final
sentence applies specifically to the behaviour of the example.

-- 
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