Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: PATCH: file completion
- X-seq: zsh-workers 9637
 
- From: "Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>
 
- To: Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>,        zsh-workers@xxxxxxxxxxxxxx
 
- Subject: Re: PATCH: file completion
 
- Date: Wed, 9 Feb 2000 18:50:39 +0000
 
- In-reply-to: <200002091625.RAA17482@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
 
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
 
- References: <200002091625.RAA17482@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
 
On Feb 9,  5:25pm, Sven Wischnowsky wrote:
} Subject: PATCH: file completion
}
} I finally got fed up with those longish while-getopts loops
} and added a small builtin (zparseopts) that can be used to replace
} such loops.
This is not a bad idea, but I repeat my frequent plea that we stop
placing so much emphasis on compact syntax.  nopts qopts 1opts 2opts ?
It's like reading Dr. Suess.
Besides, it can't support long options, which somebody at some point
is going to start yelling for.
How about
	zparseopts [ -a arraname | -A assocname | -D ] optspec ...
where optspec looks like
	optionname["+"|":"]["="arrayname]
where of course + : = in optionname can be backslashed or whatever.
The -a option would mean to use that arrayname for any optspec where
the =arrayname part was left off; the -A assocname would mean to set
assocname[optionname] with the same semantics that getopts sets OPTARG.
It could also use the GNU getopt double-colon syntax for whether an
option takes a required (one colon) or optional (two colons) argument.
It's also not clear what happens when there's an argument parsing error
of some sort; does zparseopts just quit then and ignore the rest of the 
arguments, or what?
-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com
Messages sorted by:
Reverse Date,
Date,
Thread,
Author