From: Pierre Habouzit <madcoder@debian.org>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH] Add a simple option parser.
Date: Sat, 13 Oct 2007 16:58:09 +0200 [thread overview]
Message-ID: <20071013145809.GG7110@artemis.corp> (raw)
In-Reply-To: <Pine.LNX.4.64.0710131519510.25221@racer.site>
[-- Attachment #1: Type: text/plain, Size: 4865 bytes --]
On Sat, Oct 13, 2007 at 02:39:10PM +0000, Johannes Schindelin wrote:
> Hi,
>
> On Sat, 13 Oct 2007, Pierre Habouzit wrote:
>
> > Aggregation of single switches is allowed:
> > -rC0 is the same as -r -C 0 (supposing that -C wants an arg).
>
> I'd be more interested in "-rC 0" working... Is that supported, too?
yes it is.
> > +static inline const char *get_arg(struct optparse_t *p)
> > +{
> > + if (p->opt) {
> > + const char *res = p->opt;
> > + p->opt = NULL;
> > + return res;
> > + }
> > + p->argc--;
> > + return *++p->argv;
> > +}
>
> This is only used once; I wonder if it is really that more readable having
> this as a function in its own right.
it's used twice, and it makes the code more readable I believe.
> > +static inline const char *skippfx(const char *str, const char *prefix)
>
> Personally, I do not like abbreviations like that. They do not save that
> much screen estate (skip_prefix is only 4 characters longer, but much more
> readable). Same goes for "cnt" later.
Ack I'll fix that.
> > +static int parse_long_opt(struct optparse_t *p, const char *arg,
> > + struct option *options, int count)
> > +{
> > + int i;
> > +
> > + for (i = 0; i < count; i++) {
> > + const char *rest;
> > + int flags = 0;
> > +
> > + if (!options[i].long_name)
> > + continue;
> > +
> > + rest = skippfx(arg, options[i].long_name);
> > + if (!rest && !strncmp(arg, "no-", 3)) {
> > + rest = skippfx(arg + 3, options[i].long_name);
> > + flags |= OPT_SHORT;
> > + }
>
> Would this not be more intuitive as
>
> if (!prefixcmp(arg, "no-")) {
> arg += 3;
> flags |= OPT_UNSET;
> }
> rest = skip_prefix(arg, options[i].long_name);
Yes, that can be done indeed, but the point is, we have sometimes
option whose long-name is "no-foo" (because it's what makes sense) but I
can rework that.
> Hm? (Note that I say UNSET, not SHORT... ;-)
fsck, good catch.
> > + if (!rest)
> > + continue;
> > + if (*rest) {
> > + if (*rest != '=')
> > + continue;
>
> Is this really no error? For example, "git log
> --decorate-walls-and-roofs" would not fail...
it would be an error, it will yield a "option not found".
> > +int parse_options(int argc, const char **argv,
> > + struct option *options, int count,
> > + const char * const usagestr[], int flags)
>
> Please indent by the same amount.
oops, stupid space vs. tab thing.
> > + if (arg[1] != '-') {
> > + optp.opt = arg + 1;
> > + do {
> > + if (*optp.opt == 'h')
> > + make_usage(usagestr, options, count);
>
> How about calling this "usage_with_options()"? With that name I expected
> make_usage() to return a strbuf.
will do.
> > + if (!arg[2]) { /* "--" */
> > + if (!(flags & OPT_COPY_DASHDASH))
> > + optp.argc--, optp.argv++;
>
> I would prefer this as
>
> if (!(flags & OPT_COPY_DASHDASH)) {
> optp.argc--;
> optp.argv++;
> }
>
> While I'm at it: could you use "args" instead of "optp"? It is misleading
> both in that it not only contains options (but other arguments, too) as in
> that it is not a pointer (the trailing "p" is used as an indicator of that
> very often, including git's source code).
okay.
> In the same vein, OPT_COPY_DASHDASH should be named
> PARSE_OPT_KEEP_DASHDASH.
okay.
>
> > + if (opts->short_name) {
> > + strbuf_addf(&sb, "-%c", opts->short_name);
> > + }
> > + if (opts->long_name) {
> > + strbuf_addf(&sb, opts->short_name ? ", --%s" : "--%s",
> > + opts->long_name);
> > + }
>
> Please lose the curly brackets.
>
> > + if (sb.len - pos <= USAGE_OPTS_WIDTH) {
> > + int pad = USAGE_OPTS_WIDTH - (sb.len - pos) + USAGE_GAP;
> > + strbuf_addf(&sb, "%*s%s\n", pad, "", opts->help);
> > + } else {
> > + strbuf_addf(&sb, "\n%*s%s\n", USAGE_OPTS_WIDTH + USAGE_GAP, "",
> > + opts->help);
> > + }
>
> Same here. (And I'd also make sure that the lines are not that long.)
okay.
>
> > diff --git a/parse-options.h b/parse-options.h
> > new file mode 100644
> > index 0000000..4b33d17
> > --- /dev/null
> > +++ b/parse-options.h
> > @@ -0,0 +1,37 @@
> > +#ifndef PARSE_OPTIONS_H
> > +#define PARSE_OPTIONS_H
> > +
> > +enum option_type {
> > + OPTION_BOOLEAN,
>
> I know that I proposed "BOOLEAN", but actually, you use it more like an
> "INCREMENTAL", right?
yes, I don't like _BOOLEAN either, I would have prefered _FLAG or sth
like that. INCREMENTAL is just too long.
> Other than that: I like it very much.
:P
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2007-10-13 14:58 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-13 13:29 [RFC] CLI option parsing and usage generation for porcelains Pierre Habouzit
2007-10-13 14:53 ` Wincent Colaiuta
[not found] ` <1192282153-26684-2-git-send-email-madcoder@debian.org>
2007-10-13 14:39 ` [PATCH] Add a simple option parser Johannes Schindelin
2007-10-13 14:58 ` Pierre Habouzit [this message]
[not found] ` <1192282153-26684-3-git-send-email-madcoder@debian.org>
2007-10-13 14:47 ` [PATCH] Port builtin-add.c to use the new " Johannes Schindelin
2007-10-13 15:03 ` Pierre Habouzit
2007-10-13 19:22 ` Alex Riesen
2007-10-13 20:27 ` Pierre Habouzit
[not found] ` <1192282153-26684-4-git-send-email-madcoder@debian.org>
[not found] ` <1192282153-26684-5-git-send-email-madcoder@debian.org>
[not found] ` <1192282153-26684-6-git-send-email-madcoder@debian.org>
[not found] ` <1192282153-26684-7-git-send-email-madcoder@debian.org>
[not found] ` <1192282153-26684-8-git-send-email-madcoder@debian.org>
[not found] ` <1192282153-26684-9-git-send-email-madcoder@debian.org>
[not found] ` <1192282153-26684-10-git-send-email-madcoder@debian.org>
2007-10-14 14:01 ` [PATCH] Simplify usage string printing Jonas Fonseca
2007-10-14 16:26 ` Pierre Habouzit
2007-10-13 19:16 ` [PATCH] Add a simple option parser Alex Riesen
2007-10-13 20:54 ` Pierre Habouzit
2007-10-13 22:14 ` Alex Riesen
2007-10-14 7:02 ` Pierre Habouzit
2007-10-14 14:10 ` [PATCH] Update manpages to reflect new short and long option aliases Jonas Fonseca
2007-10-14 16:26 ` Pierre Habouzit
2007-10-14 9:18 ` [RFC] CLI option parsing and usage generation for porcelains Eric Wong
2007-10-14 9:57 ` Pierre Habouzit
2007-10-14 16:54 ` [PATCH] parse-options: Allow abbreviated options when unambiguous Johannes Schindelin
2007-10-14 18:02 ` Johannes Schindelin
2007-10-14 18:08 ` Pierre Habouzit
2007-10-14 21:01 ` Eric Wong
2007-10-14 22:12 ` Johannes Schindelin
2007-10-14 22:49 ` Eric Wong
2007-10-14 22:59 ` git-svn and submodules, was " Johannes Schindelin
2007-10-15 7:07 ` git-svn and submodules Benoit SIGOURE
2007-10-15 10:00 ` Andreas Ericsson
2007-10-15 10:51 ` Benoit SIGOURE
2007-10-15 10:14 ` David Kastrup
2007-10-15 10:53 ` Benoit SIGOURE
2007-10-15 16:27 ` Andreas Ericsson
2007-10-15 14:45 ` Karl Hasselström
2007-10-15 15:14 ` .gitignore and svn:ignore [WAS: git-svn and submodules] Chris Shoemaker
2007-10-16 7:58 ` Eric Wong
2007-10-16 9:43 ` Karl Hasselström
2007-10-16 13:05 ` Chris Shoemaker
2007-10-15 15:53 ` git-svn and submodules Linus Torvalds
2007-10-15 16:17 ` Performance issue with excludes (was: Re: git-svn and submodules) Benoit SIGOURE
2007-10-15 16:34 ` Linus Torvalds
2007-10-15 16:51 ` Benoit SIGOURE
2007-10-15 17:10 ` Linus Torvalds
2007-10-15 17:38 ` Benoit SIGOURE
-- strict thread matches above, loose matches on Subject: below --
2007-10-03 21:45 [PATCH] Add a simple option parser Kristian Høgsberg
2007-10-03 23:11 ` Pierre Habouzit
2007-10-04 14:57 ` Kristian Høgsberg
2007-10-04 15:15 ` Pierre Habouzit
2007-10-04 16:31 ` Pierre Habouzit
2007-10-04 16:39 ` Johannes Schindelin
2007-10-05 10:08 ` Pierre Habouzit
2007-10-05 14:21 ` Pierre Habouzit
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20071013145809.GG7110@artemis.corp \
--to=madcoder@debian.org \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).