generals observations about completion system

generals observations about completion system

[E. Jay Berkenbilt]

As I've been playing in some depth with the completion system lately,
I've had a few general observations which I'd like to make.

The new completion system seems very powerful and highly
configurable at the low level.  This is a really nice feature -- one
that I am quickly becoming quite addicted to.  However, I suspect most
users will probably not customize it too much or write too many of
their own completion functions, and, based on the manual, I suspect
the authors share this belief.

So that means that it would be good if the "standard" completion
functions, i.e., those installed by default, were easily customizable
by users.

The primary way in which this is achieved seems to be through styles.
The zsh documentation, which seems to be well written and far ahead of
the documentation with most systems, it naturally is still somewhat
incomplete about how specific completion functions can be customized
through styles.  Also, it is up to the individual function to support
styles.

I will give a few specific examples of what I'm talking about.

 1.  I have been a Kerberos user for some time.  I like to have the
     Kerberos and non-Kerberos versions of the r* commands in my path.
     Sometimes I call them krlogin, krsh, etc. instead of rlogin, rsh,
     etc.  I wanted zsh to use rlogin's completion rules for krlogin,
     rsh's rules for krsh, and rcp's rules for krcp.  My first attempt
     at doing this was to say

     compdef -a _rlogin krlogin krsh rcp

     This, however, did not work because the code in the _rlogin
     function hard-codes the names of the commands and uses them
     in conditions to decide what specific behavior to use.  It seems
     to me that it would have been better to have three separate
     completion functions here that can share common functions to
     avoid this.  The way I worked around this was to define my own
     completion function called _krlogin which looks like this:

     #compdef krlogin krsh krcp

     # The _rlogin function is conditional on words[1], so we have to
     # fake it out to make it work.
     if [[ $words[1] == /* ]]; then
	words[1]=${words[1]:h}/${${words[1]:t}/#k/}
     else
	words[1]=${words[1]/#k/}
     fi
     _rlogin

 2.  The ssh completion function does not use the user-hosts style
     even though this style is documented.  (If it uses it, I've
     missed it.)  It knows about ssh's ability to say ssh user@host
     rather than ssh host -l user.  You can easily override the list
     of hosts to be completed by setting the hosts style for the ssh
     command, but this doesn't entirely solve the problem.  If I hit

     ssh TAB

     I get a list of all users and hosts.  There are a lot more users
     on my system than there are hosts that I ssh to.  I want to
     change ssh to complete only on hosts, not on users.  If I want
     users, I'll use -l.  There seems to be no good way to do this
     without simply copying and modifying the _ssh file.

     Now I can mitigate this somewhat by saying

     zstyle ':completion:*:*:ssh:*' users ejb

     but this doesn't entirely work either.  If the first character
     that I type doesn't match any users, then the completion system
     falls back to matching against all users.  I haven't figured out
     why whether I can do anything about this.

 3.  Sometimes I think it would be nice to have an "advice"-like
     capability (as in lisp).  That way it would be easier to write
     wrappers for things.  I'm not sure this is really a good
     idea.... I don't know enough about how bindings work in zsh to
     really have a strong opinion....

 4.  It's very hard to know what features are documented reliable
     parts of the interface and what parts aren't.  I could change the
     behavior of the ssh completion function by redefining some of its
     internally defined functions, but that would be evil and I would
     probably find that that would stop working in a future release.
     On the other hand, I feel like a lot of what I'm learning about
     zsh is just from reading the code, and the danger there of course
     is that I may accidentally rely on an internal private part of an
     interface.  Certainly the guideline that things that start with _
     are not intended to be called directly by users is a start, but
     then what about things like my workaround for krlogin?

Anyway, I understand that I'm using a development release of an
experimental version of zsh, so these aren't intended as complaints or
criticisms but more as comments or questions.  Perhaps a lot of this
has already been discussed.

All this said, I love using zsh and think it's a great program,
wrinkles and all!

--
E. Jay Berkenbilt (ejb@ql.org)  |  http://www.ql.org/q/

Re: generals observations about completion system

[Bart Schaefer]

On Sep 17,  7:33pm, E. Jay Berkenbilt wrote:
} Subject: generals observations about completion system
}
} I suspect most users will probably not customize it too much or write
} too many of their own completion functions, and, based on the manual,
} I suspect the authors share this belief.
} 
} So that means that it would be good if the "standard" completion
} functions, i.e., those installed by default, were easily customizable
} by users.

Have you tried using "compinstall"?  It does an question-and-answer menu-
driven session to establish likely completion customizations, so that an
"ordinary user" doesn't have to comprehend all the details at once, and
you end up with nice examples of style usage to look at.

} The zsh documentation [...] naturally is still somewhat incomplete

There's also PWS's work-in-progess on-line user's guide:

    http://sunsite.auc.dk/zsh/Guide/zshguide.html

} about how specific completion functions can be customized through
} styles.

It does tend to be easier to add new completion functions than it is to
document them.

} I will give a few specific examples of what I'm talking about.
} 
}      compdef -a _rlogin krlogin krsh rcp
} 
}      This, however, did not work because the code in the _rlogin
}      function hard-codes the names of the commands and uses them
}      in conditions to decide what specific behavior to use.

This same problem exists for _ssh (which it would be nice to use for
the ssh1 and ssh2 versions of those commands), and probably a couple
of others.

}      It seems to me that it would have been better to have three
}      separate completion functions here that can share common
}      functions to avoid this.

The reason that *wasn't* done was to be able to keep all the related
functions together in one file, which has to have the same name as the
function invoked for each of the commands named in the #compdef line.

However ... there isn't any reason the file _rlogin couldn't define
several functions, and issue new `compdef' commands to point rcp and
rsh at different functions.  (In fact, on systems that have `remsh',
`rsh' is not an rlogin-related function at all.)  Stay tuned.

}  2.  The ssh completion function does not use the user-hosts style
}      even though this style is documented.  (If it uses it, I've
}      missed it.)

It does use it; see the _ssh_users and _ssh_hosts functions, at the
end of Completion/User/_ssh.  They get at it via the _combination
helper function.  As documented under the users-hosts style entry:

     If set for the my-accounts tag, this is used for commands such as
     rlogin and ssh; in this case the style should contain the names of
     the user's own accounts on remote hosts.  If set for the
     other-accounts tag, it is used for commands such as talk and
     finger and should contain other people's accounts.  Finally, it
     may also be used by some commands with the accounts tag.

The trouble is that ^Xh can't descend all the way through _combination
to show you the styles and tags that it supports, so all you see are the
separate hosts and users tags.  I don't know what would be involved in
fixing that.

If you've set users-hosts and are still having trouble getting ssh to
use them, it may have something to do with that completer style we've
been discussing in the other thread.

}  3.  Sometimes I think it would be nice to have an "advice"-like
}      capability (as in lisp).  That way it would be easier to write
}      wrappers for things.

There actually is such a capability, sort of, but only compiled zmodload
modules can make use of it.  It might be possible to write an "advice"
module to expose the facility at the user level.  (I'm not going to try
that anytime soon.)

However, maybe what you're looking for is this, from "Utility Functions"
in zsh.info:
----------------------
When writing completion functions or other ZLE widgets that call
completion, it might be interesting to know about two more features
offered by the _main_complete function. The arrays compprefuncs and
comppostfuncs may be set to contain names of functions that are to be
called immediately before or after completion has been tried. The
functions will only be called once, unless they put themselves into the
arrays again.
----------------------

Hmm, it really ought to say a bit more about it than that ...

}  4.  It's very hard to know what features are documented reliable
}      parts of the interface and what parts aren't.

If it's in the documentation, then it's documented. :-)

There's also Etc/completion-style-guide in the distribution, if you're
planning to write functions that can be included in the standard system.

}      Certainly the guideline that things that start with _
}      are not intended to be called directly by users is a start, but
}      then what about things like my workaround for krlogin?

I'd have followed the advice about copying one of the existing completion
functions and modifying it, rather than rely on calling through to it.
(Hmm, I thought that advice appeared somewhere in either the docs or in
completion-style-guide, but now I can't find it.)

More from zsh.info:
----------------------
This describes the shell code for the new completion system.  It
consists of various shell functions; those beginning `comp' are to be
called directly by the user, while those beginning `_' are called by the
completion code.  The shell functions of the second set which implement
completion behaviour and which may be bound to keystrokes, are referred
to as `widgets'.

In the source distribution, the files are contained in various
subdirectories of the Completion directory.  They may have been
installed in the same structure, or into one single function directory.
The following is a description of the files found in the original
directory structure.  If you wish to alter an installed file, you will
need to copy it to some directory which appears earlier in your fpath
than the standard directory where it appears.

The convention for autoloaded functions used in completion is that they
start with an underscore; as already mentioned, the fpath/FPATH
parameter must contain the directory in which they are stored.

When compinit is run, it searches all such files accessible via
fpath/FPATH and reads the first line of each of them.  This line should
contain one of the tags described below.  Files whose first line does
not start with one of these tags are not considered to be part of the
completion system and will not be treated specially.

The # is part of the tag name and no white space is allowed after it.
The #compdef tags use the compdef function described below; the main
difference is that the name of the function is supplied implicitly.

Descriptions follow for utility functions that may be useful when
writing completion functions.  Most of these reside in the Core
subdirectory. Like the example functions for commands in the
distribution, the utility functions generating matches all follow the
convention of returning zero if they generated completions and non-zero
if no matching completions could be added.
----------------------

(The above is clipped from several chapters, you won't find it in that
order anywhere in the document.)

} Anyway, I understand that I'm using a development release of an
} experimental version of zsh, so these aren't intended as complaints or
} criticisms but more as comments or questions.  Perhaps a lot of this
} has already been discussed.

The new completion system is the reason zsh-workers had nearly as many
messages in 1999 as in its entire previous history.  It took a lot of
discussion to get it to where it is now ...

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: generals observations about completion system

[Peter Stephenson]

Bart wrote:
> It does tend to be easier to add new completion functions than it is to
> document them.

I haven't had much time for replying (have you seen the specification for
Bluetooth park mode? :-() but self-documenting functions with something
like pod, except using shell functions to strip out the bits and turn them
into yodl, should be pretty easy.  Adding comments is usually much easier
than fiddling with the full documentation.

Moving the string functions to their own file would be a step in the right
direction, too.  It's hard to know what's in utils.c.  (It's not as if the
rest of the shell doesn't consist of utilities, despite the double
negative.)

By the way, I'm finally getting a week's holiday from tomorrow and luckily
in a PC-free zone.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

Re: generals observations about completion system

[Bart Schaefer]

On Sep 19, 10:04am, Peter Stephenson wrote:
} Subject: Re: generals observations about completion system
}
} Moving the string functions to their own file would be a step in the right
} direction, too.  It's hard to know what's in utils.c.

If anyone else wants to do this:  The convention in the past for new files
has been to copy the copyright notice from one of the existing files, and
then either add or change the name of the copyright holder to that of the
current coordinator (which would be Peter).

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: generals observations about completion system

[Clint Adams]

> If anyone else wants to do this:  The convention in the past for new files
> has been to copy the copyright notice from one of the existing files, and
> then either add or change the name of the copyright holder to that of the
> current coordinator (which would be Peter).

I only moved functions that depended solely on mem.c.  Anything
involving metafication was left alone.

Index: Src/.distfiles
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/.distfiles,v
retrieving revision 1.2
diff -u -r1.2 .distfiles
--- Src/.distfiles	2000/08/16 13:34:54	1.2
+++ Src/.distfiles	2000/09/19 15:45:43
@@ -7,7 +7,7 @@
     hist.c init.c input.c jobs.c lex.c linklist.c loop.c main.c makepro.awk
     math.c mem.c mkbltnmlst.sh mkmakemod.sh mkmodindex.sh
     module.c options.c params.c parse.c pattern.c prompt.c prototypes.h
-    signals.c signals.h subst.c system.h text.c utils.c
+    signals.c signals.h string.c subst.c system.h text.c utils.c
     watch.c xmods.conf zsh.h zsh.mdd ztype.h
     zsh.rc zsh.ico
 '
Index: Src/mem.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/mem.c,v
retrieving revision 1.2
diff -u -r1.2 mem.c
--- Src/mem.c	2000/07/28 09:10:37	1.2
+++ Src/mem.c	2000/09/19 15:45:50
@@ -507,32 +507,6 @@
 }
 
 /**/
-mod_export char *
-dupstring(const char *s)
-{
-    char *t;
-
-    if (!s)
-	return NULL;
-    t = (char *) zhalloc(strlen((char *)s) + 1);
-    strcpy(t, s);
-    return t;
-}
-
-/**/
-mod_export char *
-ztrdup(const char *s)
-{
-    char *t;
-
-    if (!s)
-	return NULL;
-    t = (char *)zalloc(strlen((char *)s) + 1);
-    strcpy(t, s);
-    return t;
-}
-
-/**/
 #ifdef ZSH_MEM
 
 /*
Index: Src/string.c
===================================================================
RCS file: string.c
diff -N string.c
--- /dev/null	Tue May  5 13:32:27 1998
+++ string.c	Tue Sep 19 08:45:50 2000
@@ -0,0 +1,135 @@
+/*
+ * string.c - string manipulation
+ *
+ * This file is part of zsh, the Z shell.
+ *
+ * Copyright (c) 2000 Peter Stephenson
+ * All rights reserved.
+ *
+ * Permission is hereby granted, without written agreement and without
+ * license or royalty fees, to use, copy, modify, and distribute this
+ * software and to distribute modified versions of this software for any
+ * purpose, provided that the above copyright notice and the following
+ * two paragraphs appear in all copies of this software.
+ *
+ * In no event shall Peter Stephenson or the Zsh Development Group be liable
+ * to any party for direct, indirect, special, incidental, or consequential
+ * damages arising out of the use of this software and its documentation,
+ * even if Peter Stephenson and the Zsh Development Group have been advised of
+ * the possibility of such damage.
+ *
+ * Peter Stephenson and the Zsh Development Group specifically disclaim any
+ * warranties, including, but not limited to, the implied warranties of
+ * merchantability and fitness for a particular purpose.  The software
+ * provided hereunder is on an "as is" basis, and Peter Stephenson and the
+ * Zsh Development Group have no obligation to provide maintenance,
+ * support, updates, enhancements, or modifications.
+ */
+
+#include "zsh.mdh"
+
+/**/
+mod_export char *
+dupstring(const char *s)
+{
+    char *t;
+
+    if (!s)
+	return NULL;
+    t = (char *) zhalloc(strlen((char *)s) + 1);
+    strcpy(t, s);
+    return t;
+}
+
+/**/
+mod_export char *
+ztrdup(const char *s)
+{
+    char *t;
+
+    if (!s)
+	return NULL;
+    t = (char *)zalloc(strlen((char *)s) + 1);
+    strcpy(t, s);
+    return t;
+}
+
+/* concatenate s1, s2, and s3 in dynamically allocated buffer */
+
+/**/
+mod_export char *
+tricat(char const *s1, char const *s2, char const *s3)
+{
+    /* This version always uses permanently-allocated space. */
+    char *ptr;
+    size_t l1 = strlen(s1);
+    size_t l2 = strlen(s2);
+
+    ptr = (char *)zalloc(l1 + l2 + strlen(s3) + 1);
+    strcpy(ptr, s1);
+    strcpy(ptr + l1, s2);
+    strcpy(ptr + l1 + l2, s3);
+    return ptr;
+}
+
+/**/
+mod_export char *
+zhtricat(char const *s1, char const *s2, char const *s3)
+{
+    char *ptr;
+    size_t l1 = strlen(s1);
+    size_t l2 = strlen(s2);
+    
+    ptr = (char *)zhalloc(l1 + l2 + strlen(s3) + 1);
+    strcpy(ptr, s1);
+    strcpy(ptr + l1, s2);
+    strcpy(ptr + l1 + l2, s3);
+    return ptr;
+}
+
+/* concatenate s1 and s2 in dynamically allocated buffer */
+
+/**/
+mod_export char *
+dyncat(char *s1, char *s2)
+{
+    /* This version always uses space from the current heap. */
+    char *ptr;
+    size_t l1 = strlen(s1);
+
+    ptr = (char *)zhalloc(l1 + strlen(s2) + 1);
+    strcpy(ptr, s1);
+    strcpy(ptr + l1, s2);
+    return ptr;
+}
+
+/**/
+mod_export char *
+dupstrpfx(const char *s, int len)
+{
+    char *r = zhalloc(len + 1);
+
+    memcpy(r, s, len);
+    r[len] = '\0';
+    return r;
+}
+
+/**/
+mod_export char *
+ztrduppfx(const char *s, int len)
+{
+    char *r = zalloc(len + 1);
+
+    memcpy(r, s, len);
+    r[len] = '\0';
+    return r;
+}
+
+/* Append a string to an allocated string, reallocating to make room. */
+
+/**/
+mod_export char *
+appstr(char *base, char const *append)
+{
+    return strcat(realloc(base, strlen(base) + strlen(append) + 1), append);
+}
Index: Src/utils.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/utils.c,v
retrieving revision 1.19
diff -u -r1.19 utils.c
--- Src/utils.c	2000/09/18 06:50:55	1.19
+++ Src/utils.c	2000/09/19 15:46:00
@@ -3438,86 +3438,6 @@
 }
 
 /**/
-mod_export char *
-dupstrpfx(const char *s, int len)
-{
-    char *r = zhalloc(len + 1);
-
-    memcpy(r, s, len);
-    r[len] = '\0';
-    return r;
-}
-
-/**/
-mod_export char *
-ztrduppfx(const char *s, int len)
-{
-    char *r = zalloc(len + 1);
-
-    memcpy(r, s, len);
-    r[len] = '\0';
-    return r;
-}
-
-/* Append a string to an allocated string, reallocating to make room. */
-
-/**/
-mod_export char *
-appstr(char *base, char const *append)
-{
-    return strcat(realloc(base, strlen(base) + strlen(append) + 1), append);
-}
-
-/* concatenate s1, s2, and s3 in dynamically allocated buffer */
-
-/**/
-mod_export char *
-tricat(char const *s1, char const *s2, char const *s3)
-{
-    /* This version always uses permanently-allocated space. */
-    char *ptr;
-    size_t l1 = strlen(s1);
-    size_t l2 = strlen(s2);
-
-    ptr = (char *)zalloc(l1 + l2 + strlen(s3) + 1);
-    strcpy(ptr, s1);
-    strcpy(ptr + l1, s2);
-    strcpy(ptr + l1 + l2, s3);
-    return ptr;
-}
-
-/**/
-mod_export char *
-zhtricat(char const *s1, char const *s2, char const *s3)
-{
-    char *ptr;
-    size_t l1 = strlen(s1);
-    size_t l2 = strlen(s2);
-    
-    ptr = (char *)zhalloc(l1 + l2 + strlen(s3) + 1);
-    strcpy(ptr, s1);
-    strcpy(ptr + l1, s2);
-    strcpy(ptr + l1 + l2, s3);
-    return ptr;
-}
-
-/* concatenate s1 and s2 in dynamically allocated buffer */
-
-/**/
-mod_export char *
-dyncat(char *s1, char *s2)
-{
-    /* This version always uses space from the current heap. */
-    char *ptr;
-    size_t l1 = strlen(s1);
-
-    ptr = (char *)zhalloc(l1 + strlen(s2) + 1);
-    strcpy(ptr, s1);
-    strcpy(ptr + l1, s2);
-    return ptr;
-}
-
-/**/
 static int
 upchdir(int n)
 {
Index: Src/zsh.mdd
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/zsh.mdd,v
retrieving revision 1.2
diff -u -r1.2 zsh.mdd
--- Src/zsh.mdd	2000/07/30 17:03:53	1.2
+++ Src/zsh.mdd	2000/09/19 15:46:00
@@ -8,7 +8,7 @@
 objects="builtin.o compat.o cond.o exec.o glob.o hashtable.o \
 hist.o init.o input.o jobs.o lex.o linklist.o loop.o math.o \
 mem.o module.o options.o params.o parse.o pattern.o prompt.o signals.o \
-signames.o subst.o text.o utils.o watch.o"
+signames.o string.o subst.o text.o utils.o watch.o"
 
 headers="../config.h system.h zsh.h sigcount.h signals.h \
 prototypes.h hashtable.h ztype.h"

Thoughts on self-documenting functions

[Bart Schaefer]

On Sep 19, 10:04am, Peter Stephenson wrote:
} Subject: Re: generals observations about completion system
}
} Bart wrote:
} > It does tend to be easier to add new completion functions than it is to
} > document them.
} 
} [...] self-documenting functions with something
} like pod, except using shell functions to strip out the bits and turn them
} into yodl, should be pretty easy.  Adding comments is usually much easier
} than fiddling with the full documentation.

I actually have a bit of experience with this, and I have reservations
about how effective it will be.

In Z-Mail, which has a shell-like scripting language with "#...\n"
comments, each function may contain a block that looks like

	#%
	# Documentation goes here
	# across several lines if
	# necessary
	#%

The zscript parser grabs those comments and uses them to generate on-line
help in the GUI.  Also, if you run `func -?' the documentation block is
printed (with the leading '# ' stripped from each line) instead of
executing the real function body.

POD's biggest advantage over this scheme is that you don't have to put a
comment character on every line, which makes editing the doc a lot easier
should you ever need to change it.  The value of that convenience should
not be underestimated; zmail was heavily customized through zscript by
each of several organizations that bought it, but I never heard of anyone
who made use of this inline doc feature. Conversely, the use of POD is
quite common.

In any case, in both zscript and POD, the support for stripping the doc
out of the function is built in to the parser.  Since I don't think PWS
is suggesting we diddle with zsh's parser, we can't avoid using comments
(any other approach, e.g., here-documents, would store the documentation
as part of the function definition when it gets loaded).  That's my first
reservation.

The second is with the idea of "generating yodl" from the text in the
comment.  That seems doomed from the start; yodl's designed to be the
source language, not the generated one, and consequently has a whole
syntactic menagerie that can't be inferred from un-marked-up text, which
is all we can expect anyone to write in a shell script comment -- no one
will want to document their functions twice, so whatever form we choose
ought to be plainly readable without preprocessing.

One thought that I had is to put the documentation into its own function,
which is then unfunction'd after the whole file has been autoloaded.  So
each file _xxx would look something like:

    _xxx_doc () {
	some sort of documentation format
    }

    _xxx () {
        the actual function
    }

    unfunction _xxx_doc
    _xxx "$@"

This way, the doc format wouldn't have to be a comment, but would still
get flushed out of zsh's memory after the file is loaded.  On the other
hand, I think redefining _xxx that way prevents taking full advantage of
memory-mapped .zwc files, which is also undesirable.  However, using a
function might let us do something clever with shell expansions to mark
up the documentation for conversion to yodl.

Anyway, no conclusions yet, just musings.

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: generals observations about completion system

[Sven Wischnowsky]

E. Jay Berkenbilt wrote:

Most of this has been answered or is being thought about or worked
upon elsewhere, so I'll jump to:

> ...
> 
>  2.  The ssh completion function does not use the user-hosts style
>      even though this style is documented.  (If it uses it, I've
>      missed it.)  It knows about ssh's ability to say ssh user@host
>      rather than ssh host -l user.  You can easily override the list
>      of hosts to be completed by setting the hosts style for the ssh
>      command, but this doesn't entirely solve the problem.  If I hit
> 
>      ssh TAB
> 
>      I get a list of all users and hosts.  There are a lot more users
>      on my system than there are hosts that I ssh to.  I want to
>      change ssh to complete only on hosts, not on users.  If I want
>      users, I'll use -l.  There seems to be no good way to do this
>      without simply copying and modifying the _ssh file.

Look at the `tag-order' style (probably the most important style). If
you're feeling bold, look at the `hidden' style (probably together
with `group-name'; it would allow you to just keep the user names from 
being listed).

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de