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