Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author



has there been any talk / thought / action as to separate the zsh
globbing code into its own library?  (as Zle nowadays seems to be,
sort of)

Background: I am one of the Perl Porters and there is one sore wound:
Perl uses csh for filename globbing (you may boo now).  Using external
program is a) ugly b) slow c) security risk d) in certain environments
csh globbing is plain broken (`glob *.c` may not return NUL-separated
string of filenames, glob cannot return >1kB stuff, things like that).
All that goes against the grain of Perl. *)

We briefly looked into tcsh -- but why stop there when there is a
much better glob out there.

What would be needed would be as small subdirectory as possible
in addition to zsh's glob.c that could be built stand alone into
a (at least) libzglob.a.

I realize that this is not trivial because the glob.c seems to
use a lot of general zsh structs and call other zsh functions,
ansi2knr, makepro.sh, for some things it may be useful to use
the "parent" software's (Perl in this case) function instead of
the zsh ones (for example garbage collection comes to mind).
But some of you zsh-workers is interested I am prepared to
co-operate with you in modularizing the Zsh Glob.

If this happens I can see one zsh API change need right now: glob()
should be 'thread-safe' in that the various glob options should be
passed in as arguments (a bitmask? a struct?) instead of being part of
the 'global' zsh state -- as there is no zsh opts[] if only the glob
lib is being used.

*) somebody might argue the a) point here :-)

$jhi++; # http://www.iki.fi/~jhi/
        # There is this special biologist word we use for 'stable'.
        # It is 'dead'. -- Jack Cohen

Messages sorted by: Reverse Date, Date, Thread, Author