Re: Fun with zsh (Re: Associative array ordering (Re: Example function))

Re: Fun with zsh (Re: Associative array ordering (Re: Example function))

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Feb 5,  8:45am, Sven Wischnowsky wrote:
> } Subject: Re: Fun with zsh (Re: Associative array ordering (Re: Example fun
> }
> }  pindex(GLOB_COMPLETE)
> }  item(tt(GLOB_COMPLETE))(
> }  When the current word has a glob pattern, do not insert all the words
> } +resulting from the expansion but collect matches as for completion and
>                                     ^^^^^^^^^^^^^^^^^^^^^^
> 				    Something about this phrase
> 				    bothers me.  "generate matches"?

Considering that we often use the word generate for this, it would be
better, yes.

> } +cycle through them like tt(MENU_COMPLETE). If no matches are found, a
> } +`tt(*)' is added to the end of the word or inserted at the cursor if
> } +tt(COMPLETE_IN_WORD) is set, and completion is attempted again using
> } +pattern matching.  Since this doesn't use globbing, it not only for
>                                                        ^^*^^^^^^^^^^^^
> 						       it is not only?
> 						       it works not only?

I accidentally removed the `works', oops.

Thanks!

Bye
 Sven

diff -u ood/Zsh/options.yo Doc/Zsh/options.yo
--- ood/Zsh/options.yo	Fri Feb  5 09:55:15 1999
+++ Doc/Zsh/options.yo	Fri Feb  5 09:56:09 1999
@@ -340,11 +340,11 @@
 pindex(GLOB_COMPLETE)
 item(tt(GLOB_COMPLETE))(
 When the current word has a glob pattern, do not insert all the words
-resulting from the expansion but collect matches as for completion and
+resulting from the expansion but generate matches as for completion and
 cycle through them like tt(MENU_COMPLETE). If no matches are found, a
 `tt(*)' is added to the end of the word or inserted at the cursor if
 tt(COMPLETE_IN_WORD) is set, and completion is attempted again using
-pattern matching.  Since this doesn't use globbing, it not only for
+pattern matching.  Since this doesn't use globbing, it works not only for
 files but for all completions, such as options, user names, etc.
 )
 pindex(GLOB_DOTS)

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

Re: Fun with zsh (Re: Associative array ordering (Re: Example function))

[Sven Wischnowsky]

Bart Schaefer wrote:

> The manual says of GLOB_COMPLETE, "If no matches are found, a `*' is added
> to the end of the word or inserted at the cursor if tt(COMPLETE_IN_WORD)
> is set, and expansion is attempted again."  Now, (I*)* _IS_ a glob pattern,
> so this makes sense.
> 
> That also means that with globcomplete,
> 
> zsh% echo (I)<TAB>
> zsh% echo INSTALL
> 
> which in fact is what happens.  [[ INSTALL = (I) ]] is definitely false ...
> is globcomplete really using pattern matching the way you say?

Yes, but [[ INSTALL = (I)* ]] is true. I think we should just make
this clearer in the docs.

Bye
 Sven

--- od/Zsh/options.yo	Wed Feb  3 12:07:31 1999
+++ Doc/Zsh/options.yo	Fri Feb  5 08:44:22 1999
@@ -331,11 +340,12 @@
 pindex(GLOB_COMPLETE)
 item(tt(GLOB_COMPLETE))(
 When the current word has a glob pattern, do not insert all the words
-resulting from the expansion but cycle through them like
-tt(MENU_COMPLETE). If no matches are found, a `tt(*)' is added to the end of the
-word or inserted at the cursor if tt(COMPLETE_IN_WORD) is set, and expansion
-is attempted again.  Using patterns works not only for files but for all
-completions, such as options, user names, etc.
+resulting from the expansion but collect matches as for completion and
+cycle through them like tt(MENU_COMPLETE). If no matches are found, a
+`tt(*)' is added to the end of the word or inserted at the cursor if
+tt(COMPLETE_IN_WORD) is set, and completion is attempted again using
+pattern matching.  Since this doesn't use globbing, it not only for
+files but for all completions, such as options, user names, etc.
 )
 pindex(GLOB_DOTS)
 cindex(globbing, of . files)

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

Re: Fun with zsh (Re: Associative array ordering (Re: Example function))

[Bart Schaefer]

On Feb 4,  9:06am, Sven Wischnowsky wrote:
} Subject: Re: Fun with zsh (Re: Associative array ordering (Re: Example fun
}
} 
} Bart Schaefer wrote:
} 
} > So if your patch somehow makes (I*) complete, something weird is going on.
} 
} Something weird indeed: me again, forgetting to mention the option
} globcomplete. *Only* if that option is set, (I*) will complete to
} INSTALL.
} Now one may argue that (I*) isn't a glob pattern so an option named
} *glob*complete shouldn't make this happen. But the name of the option
} has historical reasons, the option uses pattern matching (not
} globbing) to match possible completions, and indeed:
} 
}   [[ INSTALL = (I*) ]] && echo yep, indeed

That's interesting.

The manual says of GLOB_COMPLETE, "If no matches are found, a `*' is added
to the end of the word or inserted at the cursor if tt(COMPLETE_IN_WORD)
is set, and expansion is attempted again."  Now, (I*)* _IS_ a glob pattern,
so this makes sense.

That also means that with globcomplete,

zsh% echo (I)<TAB>
zsh% echo INSTALL

which in fact is what happens.  [[ INSTALL = (I) ]] is definitely false ...
is globcomplete really using pattern matching the way you say?

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

Re: Fun with zsh (Re: Associative array ordering (Re: Example function))

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Feb 3,  4:00pm, Sven Wischnowsky wrote:
> } Subject: Re: Fun with zsh (Re: Associative array ordering (Re: Example fun
> } 
> } Bart Schaefer wrote:
> } 
> } > Following application of your patch, using 3.1.5-pws-6 zsh -f,
> } > 
> } >     zsh% foo=('(I*)<TAB>
> } > 
> } > only feeps
> } 
> } Whew. The first behavior is the correct one, since the completion code 
> } should take the `(I*)' as the prefix of the string to complete and as
> } long as you don't have a file with a name starting with this, nothing
> } should be matched.
> 
> But I *DO* have a file beginning with "I" -- $PWD is the zsh source root,
> so the INSTALL file is there.  (I*) apparently isn't a glob pattern:
> 
> zagzig% echo (I*)    
> zsh: no matches found: (I*)
> zagzig% echo (I*|)
> INSTALL
> 
> So if your patch somehow makes (I*) complete, something weird is going on.

Something weird indeed: me again, forgetting to mention the option
globcomplete. *Only* if that option is set, (I*) will complete to
INSTALL.
Now one may argue that (I*) isn't a glob pattern so an option named
*glob*complete shouldn't make this happen. But the name of the option
has historical reasons, the option uses pattern matching (not
globbing) to match possible completions, and indeed:

  [[ INSTALL = (I*) ]] && echo yep, indeed

Ok?

Bye
 Sven


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

Re: Fun with zsh (Re: Associative array ordering (Re: Example function))

[Bart Schaefer]

On Feb 3,  4:00pm, Sven Wischnowsky wrote:
} Subject: Re: Fun with zsh (Re: Associative array ordering (Re: Example fun
}
} 
} Bart Schaefer wrote:
} 
} > Following application of your patch, using 3.1.5-pws-6 zsh -f,
} > 
} >     zsh% foo=('(I*)<TAB>
} > 
} > only feeps
} 
} Whew. The first behavior is the correct one, since the completion code 
} should take the `(I*)' as the prefix of the string to complete and as
} long as you don't have a file with a name starting with this, nothing
} should be matched.

But I *DO* have a file beginning with "I" -- $PWD is the zsh source root,
so the INSTALL file is there.  (I*) apparently isn't a glob pattern:

zagzig% echo (I*)    
zsh: no matches found: (I*)
zagzig% echo (I*|)
INSTALL

So if your patch somehow makes (I*) complete, something weird is going on.

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

Re: Fun with zsh (Re: Associative array ordering (Re: Example function))

[Sven Wischnowsky]

Bart Schaefer wrote:

> Following application of your patch, using 3.1.5-pws-6 zsh -f,
> 
>     zsh% foo=('(I*)<TAB>
> 
> only feeps, but
> 
>     zsh% foo(
>     array> '(I*)<TAB>
> 
> autolists the entire contents of the current directory.
> 
> This is the same as the 3.0.5 behavior, but it still seems odd to me.

Whew. The first behavior is the correct one, since the completion code 
should take the `(I*)' as the prefix of the string to complete and as
long as you don't have a file with a name starting with this, nothing
should be matched.

Making this work in every position in arrays wasn't that easy since
the lexer sometimes reported that it was in command position and there 
it started to parse the string itself instead of reporting it as one
string token. In fact, to avoid fiddling with the lexer, I had to add
an in-array-value-flag in get_comp_string (to recognise the end if you 
are completing something like `foo=( ... ); frob <TAB>').

People using the new style completion stuff (and the new-completion-examples
find) who test the thing quoted above will notice that it completes
files beginning with `I' in this case. This is due to the parameter
handling in pfiles(). More precisely, this is due to the fact that we
still haven't got a way to quote strings resulting from a parameter
expansion (supporting the `q' modifier for parameter expansion has
long been on the wish list but still isn't implemented).

Bye
 Sven

diff -u os/Zle/zle_tricky.c Src/Zle/zle_tricky.c
--- os/Zle/zle_tricky.c	Wed Feb  3 12:07:22 1999
+++ Src/Zle/zle_tricky.c	Wed Feb  3 15:46:24 1999
@@ -919,7 +919,7 @@
 static char *
 get_comp_string(void)
 {
-    int t0, tt0, i, j, k, cp, rd, sl, ocs, ins, oins;
+    int t0, tt0, i, j, k, cp, rd, sl, ocs, ins, oins, inarr, ia, parct;
     char *s = NULL, *linptr, *tmp, *p, *tt = NULL;
 
     zsfree(brbeg);
@@ -982,7 +982,7 @@
 	inpush(dupstrspace((char *) linptr), 0, NULL);
 	strinbeg();
 	stophist = 2;
-	i = tt0 = cp = rd = ins = oins = 0;
+	i = tt0 = cp = rd = ins = oins = inarr = parct = ia = 0;
 
 	/* This loop is possibly the wrong way to do this.  It goes through *
 	 * the previously massaged command line using the lexer.  It stores *
@@ -1001,7 +1001,21 @@
 	    linredir = (inredir && !ins);
 	    oins = ins;
 	    /* Get the next token. */
+	    if (inarr)
+		incmdpos = 0;
 	    ctxtlex();
+	    if (tok == ENVARRAY) {
+		inarr = 1;
+		zsfree(varname);
+		varname = ztrdup(tokstr);
+	    } else if (tok == INPAR)
+		parct++;
+	    else if (tok == OUTPAR) {
+		if (parct)
+		    parct--;
+		else
+		    inarr = 0;
+	    }
 	    if (inredir)
 		rdstr = tokstrings[tok];
 	    if (tok == DINPAR)
@@ -1043,6 +1057,7 @@
 		clwpos = i;
 		cp = lincmd;
 		rd = linredir;
+		ia = inarr;
 		if (inwhat == IN_NOTHING && incond)
 		    inwhat = IN_COND;
 	    } else if (linredir)
@@ -1084,8 +1099,13 @@
 	zsfree(clwords[clwnum]);
 	clwords[clwnum] = NULL;
 	t0 = tt0;
-	lincmd = cp;
-	linredir = rd;
+	if (ia) {
+	    lincmd = linredir = 0;
+	    inwhat = IN_ENV;
+	} else {
+	    lincmd = cp;
+	    linredir = rd;
+	}
 	strinend();
 	inpop();
 	errflag = zleparse = 0;
@@ -3313,7 +3333,12 @@
 	    case IN_ENV:
 		compcontext = "value";
 		compcommand = varname;
-		usea = 0;
+		if (!clwpos) {
+		    clwpos = 1;
+		    zsfree(clwords[1]);
+		    clwords[1] = ztrdup(s);
+		}
+		aadd = 1;
 		break;
 	    case IN_COND:
 		compcontext = "condition";

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

Re: Fun with zsh (Re: Associative array ordering (Re: Example function))

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Feb 2,  6:19pm, Sven Wischnowsky wrote:
> } Subject: Re: Fun with zsh (Re: Associative array ordering (Re: Example fun
> }
> } > BTW, while fooling with this, I discovered that autolist output is not
> } > properly cleared when M-x is the next thing typed (execute-named-cmd).
> } 
> } Hm. With `execute-named-cmd' I see the list being pushed one line down 
> } and the prompt appearing above it. But with C-r and C-s I see the list
> } being partly overwritten by the prompt.
> 
> That's right, but I think they should all just erase the listing entirely.

I came to the same conclusion yesterday evening, so here is the patch.

Bye
 Sven

P.S.: Is there really no easier way to remove the list without messing 
      up the cursor position?

diff -u os/Zle/zle_hist.c Src/Zle/zle_hist.c
--- os/Zle/zle_hist.c	Mon Feb  1 10:54:26 1999
+++ Src/Zle/zle_hist.c	Wed Feb  3 11:38:27 1999
@@ -663,6 +663,11 @@
     static char *previous_search = NULL;
     static int previous_search_len = 0;
 
+    invalidatelist();
+    moveto(0, 0);
+    clearflag = 0;
+    resetneeded = 1; 
+
     strcpy(ibuf, ISEARCH_PROMPT);
     memcpy(ibuf + NORM_PROMPT_POS, (dir == 1) ? "fwd" : "bck", 3);
     remember_edits();
@@ -943,6 +948,10 @@
 	zsfree(visrchstr);
 	visrchstr = NULL;
     }
+    invalidatelist();
+    moveto(0, 0);
+    clearflag = 0;
+    resetneeded = 1; 
     statusline = sbuf;
     sbuf[0] = (visrchsense == -1) ? '?' : '/';
     selectkeymap("main", 1);
diff -u os/Zle/zle_main.c Src/Zle/zle_main.c
--- os/Zle/zle_main.c	Mon Feb  1 10:54:26 1999
+++ Src/Zle/zle_main.c	Wed Feb  3 11:38:41 1999
@@ -792,6 +792,10 @@
 
     if (statusline)
 	return;
+    invalidatelist();
+    moveto(0, 0);
+    clearflag = 0;
+    resetneeded = 1; 
     statusline = "Describe key briefly: _";
     statusll = strlen(statusline);
     zrefresh();
diff -u os/Zle/zle_misc.c Src/Zle/zle_misc.c
--- os/Zle/zle_misc.c	Mon Feb  1 10:54:27 1999
+++ Src/Zle/zle_misc.c	Wed Feb  3 11:38:34 1999
@@ -612,6 +612,10 @@
     char *ptr;
     char *okeymap = curkeymapname;
 
+    invalidatelist();
+    moveto(0, 0);
+    clearflag = 0;
+    resetneeded = 1; 
     cmdbuf = halloc(l + NAMLEN + 2);
     strcpy(cmdbuf, prmt);
     statusline = cmdbuf;
diff -u os/Zle/zle_vi.c Src/Zle/zle_vi.c
--- os/Zle/zle_vi.c	Mon Feb  1 10:54:28 1999
+++ Src/Zle/zle_vi.c	Wed Feb  3 11:38:00 1999
@@ -816,6 +816,10 @@
 void
 vicapslockpanic(void)
 {
+    invalidatelist();
+    moveto(0, 0);
+    clearflag = 0;
+    resetneeded = 1; 
     zbeep();
     statusline = "press a lowercase key to continue";
     statusll = strlen(statusline);


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

Re: Fun with zsh (Re: Associative array ordering (Re: Example function))

[Bart Schaefer]

On Feb 2,  6:19pm, Sven Wischnowsky wrote:
} Subject: Re: Fun with zsh (Re: Associative array ordering (Re: Example fun
}
} > BTW, while fooling with this, I discovered that autolist output is not
} > properly cleared when M-x is the next thing typed (execute-named-cmd).
} 
} Hm. With `execute-named-cmd' I see the list being pushed one line down 
} and the prompt appearing above it. But with C-r and C-s I see the list
} being partly overwritten by the prompt.

That's right, but I think they should all just erase the listing entirely.
I see now that they don't do so in 3.0.5 either, so perhaps this is just
my "why the !*&^% are all these options I don't want turned on by default?"
showing again.

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

Re: Fun with zsh (Re: Associative array ordering (Re: Example function))

[Sven Wischnowsky]

Bart Schaefer wrote:

> Following application of your patch, using 3.1.5-pws-6 zsh -f,
> 
>     zsh% foo=('(I*)<TAB>
> 
> only feeps, but
> 
>     zsh% foo(
>     array> '(I*)<TAB>
> 
> autolists the entire contents of the current directory.
> 
> This is the same as the 3.0.5 behavior, but it still seems odd to me.

It is, but it's hard to fix. In the first case the lexer reports the
whole string (`(I*)x', the `x' was added by the completion code) as a
string token. In the second case it reports the tokens for the `(' and 
so on separately. I'll have a deeper look into this, but not today, I
think.

> BTW, while fooling with this, I discovered that autolist output is not
> properly cleared when M-x is the next thing typed (execute-named-cmd).

Hm. With `execute-named-cmd' I see the list being pushed one line down 
and the prompt appearing above it. But with C-r and C-s I see the list 
being partly overwritten by the prompt.

Bye
 Sven


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

Re: Fun with zsh (Re: Associative array ordering (Re: Example function))

[Bart Schaefer]

On Feb 2,  1:26pm, Sven Wischnowsky wrote:
} Subject: Re: Fun with zsh (Re: Associative array ordering (Re: Example fun
}
} In the previous message Bart wrote:
} 
} > That's obviously wrong here in more ways than one, and in fact my own
} > just-compiled copy of zsh dumps core when I do the same thing.
} 
} I'm not sure, in which ways zsh is wrong to do completion here. After
} all, it gets TABs. And even inside array values completion may be
} useful, don't you think?

I don't mean that it shouldn't do completion at all, just that it seemed
to be completing the wrong thing.

Following application of your patch, using 3.1.5-pws-6 zsh -f,

    zsh% foo=('(I*)<TAB>

only feeps, but

    zsh% foo(
    array> '(I*)<TAB>

autolists the entire contents of the current directory.

This is the same as the 3.0.5 behavior, but it still seems odd to me.

[Interestingly, with _my_ otherwise incorrect patch, doing

    zsh% foo(
    array> '(I*|)<TAB>

(note the alternation syntax) expands the word to INSTALL, but with
Sven's patch it autolists again.]

BTW, while fooling with this, I discovered that autolist output is not
properly cleared when M-x is the next thing typed (execute-named-cmd).

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

Re: Fun with zsh (Re: Associative array ordering (Re: Example function))

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Feb 2,  3:59am, Bart Schaefer wrote:
> } Subject: Re: Fun with zsh (Re: Associative array ordering (Re: Example fun
> }
> } On Feb 2, 12:42pm, Helmut Jarausch wrote:
> } } array> '(*.bz)AIcons-1.5.tar.bz2bzip -dc'
> } }               ^^^^^^^^^^^^^^^^^^   where does this come from?
> } 
> } If you did cut and paste, that's showing up because there's a tab
> } 
> } That's obviously wrong here in more ways than one, and in fact my own
> } just-compiled copy of zsh dumps core when I do the same thing.
> 
> I think this fixes it; at least, it prevents my crash, but I'm not sure
> it's otherwise correct.  Help, Sven!

[I was just writing my answer to Bart's previous message when this
came, a few seconds later...]

> -    char *s = findcmd(cmdstr, 1);
> +    char *s = incmd ? findcmd(cmdstr, 1) : os;

`incmd' is non-zero if we are completing the command string itself
(first word). So this would make `pattern compctl's be correctly
lookup up only when completing that.

Use the one below instead, which avoids using `pattern compctl's if we 
are not completing a for a normal command.

In the previous message Bart wrote:

> That's obviously wrong here in more ways than one, and in fact my own
> just-compiled copy of zsh dumps core when I do the same thing.

I'm not sure, in which ways zsh is wrong to do completion here. After
all, it gets TABs. And even inside array values completion may be
useful, don't you think?


Bye
 Sven

--- os/Zle/zle_tricky.c	Mon Feb  1 10:54:28 1999
+++ Src/Zle/zle_tricky.c	Tue Feb  2 13:18:02 1999
@@ -3667,10 +3667,11 @@
     }
     /* Then search the pattern compctls, with the command name and the *
      * full pathname of the command. */
-    makecomplistpc(os, incmd);
-    if (!(ccont & CC_CCCONT))
-	return;
-
+    if (cmdstr) {
+	makecomplistpc(os, incmd);
+	if (!(ccont & CC_CCCONT))
+	    return;
+    }
     /* If the command string starts with `=', try the path name of the *
      * command. */
     if (cmdstr && cmdstr[0] == Equals) {

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

Re: Fun with zsh (Re: Associative array ordering (Re: Example function))

[Bart Schaefer]

On Feb 2,  3:59am, Bart Schaefer wrote:
} Subject: Re: Fun with zsh (Re: Associative array ordering (Re: Example fun
}
} On Feb 2, 12:42pm, Helmut Jarausch wrote:
} } array> '(*.bz)AIcons-1.5.tar.bz2bzip -dc'
} }               ^^^^^^^^^^^^^^^^^^   where does this come from?
} 
} If you did cut and paste, that's showing up because there's a tab
} 
} That's obviously wrong here in more ways than one, and in fact my own
} just-compiled copy of zsh dumps core when I do the same thing.

I think this fixes it; at least, it prevents my crash, but I'm not sure
it's otherwise correct.  Help, Sven!

Index: Src/Zle/zle_tricky.c
===================================================================
RCS file: /extra/cvsroot/zsh/zsh-3.1/Src/Zle/zle_tricky.c,v
retrieving revision 1.46
diff -u -r1.46 zle_tricky.c
--- zle_tricky.c	1999/02/01 17:26:44	1.46
+++ zle_tricky.c	1999/02/02 12:03:54
@@ -3708,7 +3708,7 @@
 {
     Patcomp pc;
     Comp pat;
-    char *s = findcmd(cmdstr, 1);
+    char *s = incmd ? findcmd(cmdstr, 1) : os;
 
     for (pc = patcomps; pc; pc = pc->next) {
 	if ((pat = parsereg(pc->pat)) &&

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

Re: Fun with zsh (Re: Associative array ordering (Re: Example function))

[Bart Schaefer]

On Feb 2, 12:42pm, Helmut Jarausch wrote:
} Subject: Re: Fun with zsh (Re: Associative array ordering (Re: Example fun
}
} When I enter these lines (except for >> ofcourse) my zshell (compiled with
} all patches yesterday) reacts quite strange 
} 
} I get
} 25 % map=(
} array> '(*.(gz|Z))zcat' 
} array> '(*.bz2)bzip2 -dc'
} array> '(*.bz)AIcons-1.5.tar.bz2bzip -dc'
}               ^^^^^^^^^^^^^^^^^^   where does this come from?

If you did cut and paste, that's showing up because there's a tab
character in my text, and when you pasted it zsh did file completion
for you.

That's obviously wrong here in more ways than one, and in fact my own
just-compiled copy of zsh dumps core when I do the same thing.

Sven?

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

Fun with zsh (Re: Associative array ordering (Re: Example function))

[Bart Schaefer]

On Feb 2,  9:01am, Sven Wischnowsky wrote:
} Subject: Re: Associative array ordering and selective unset (Re: Example f
}
} Bart Schaefer wrote:
} 
} > Now change the assignment a little:
} > 
} >         map=('*.(gz|Z)' ': 1; zcat
} >              '*.bz2' ': 2; bzip2 -dc'
} >              '*.bz' ': 3; bzip -dc'
} >              '*' ': 4; <')
} 
} Hmm, I like this. For bigger arrays one would have to use `01' and so
} on, but this should be acceptible.

Somewhat off-topic, but how about this trick?  (Where map is a plain array
this time.)

    map=(
    	'(*.(gz|Z))	zcat' 
	'(*.bz2)	bzip2 -dc'
	'(*.bz)		bzip -dc'
	'(*)		<'
	)
    eval 'for i do case $i in' ${(j( $i;; ))map} '$i;; esac done'

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