Complete.Org: Mailing Lists: Archives: freeciv-dev: September 2001:
[Freeciv-Dev] Re: [RFC PATCH] init_techs
Home

[Freeciv-Dev] Re: [RFC PATCH] init_techs

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Justin Moore <justin@xxxxxxxxxxx>
Cc: Freeciv Developers <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: [RFC PATCH] init_techs
From: Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Sat, 22 Sep 2001 23:04:38 +0200
Reply-to: rf13@xxxxxxxxxxxxxxxxxxxxxx

On Sat, Sep 22, 2001 at 04:48:01PM -0400, Justin Moore wrote:
> 
> > >    I posted a perl-like split a little while back, but got very little
> > > response other than, "Boy, that's kind of neat."  Is there interest in
> > > someone (or me) rewriting some of the parsing code?  I don't think I have
> > > anything better to do this weekend. :)
> >
> > I would really love to see this.  Some small patches I've been meaning to
> > do hang on the lack of proper parsing.
> 
>    My eyes hurt.
> 
>    I'm in the process of resurrecting my split patch, but I'm learning
> how, uhm, "robust" the command line-parsing is.  All the following
> commands are equivalent on the server:
> 
> set scorelog 1
> /set scorelog 1
>       /set scorelog 1
> !@#$%^&*()/set scorelog 1
> /!@#$%^&*()set scorelog 1
> 
>    I can see 1, 2, and maybe 3 as being valid.  But is there really any
> reason to make the code as complex as it is just so it can handle cases 4
> and 5?  Yes, I know, be conservative in what you send and liberal in what
> you accept, but I think this may be a bit overboard.

Ack. The parsing could be more strict.

> The command-line parsing could/should probably be implemented this
> way:
> 
>   /* ... */
>   strip_leading_whitespace();
>   handle_server_char(); /* the '/', can/should keep the if statement */
>   split(pattern, input);  /* Get command in one buf, all args in other */
>   lookup_command(command); /* Get a callback function */
>   command_func(args);
>   /* ... */
> 
>    If the command they entered was invalid, tell them so.  The command
> struct could easily be modified to facilitate a change by associating a
> function pointer with it.  Thus:
> 
> typedef void (*command_func)(char *args);
> 
> struct command {
>   char *name;              /* name - will be matched by unique prefix   */
>   enum cmdlevel_id level;  /* access level required to use the command  */
>   char *synopsis;          /* one or few-line summary of usage */
>   char *short_help;        /* one line (about 70 chars) description */
>   char *extra_help;        /* extra help information; will be line-wrapped */
>   command_func *fptr;      /* Pointer to a callback function */
> };
> 
> void set_cmd(char *args);
> void hard_cmd(char *args);
> void wall_cmd(char *args);
> /* ... */
> static struct command commands[] = {
>   /* ... */
>   {"set",       ALLOW_CTRL,
>    N_("set <option-name> <value>"),
>    N_("Set server options."),
>    set_cmd
>   },
>   {"hard",      ALLOW_CTRL,
>    /* TRANS: translate text between <> only */
>    N_("hard\n"
>       "hard <player-name>"),
>    N_("Set one or all AI players to 'hard'."),
>    N_("With no arguments, sets all AI players to skill level 'hard', and "
>       "sets the default level for any new AI players to 'hard'.  With an "
>       "argument, sets the skill level for that player only.")
>    hard_cmd
>   },
>   {"wall",      ALLOW_HACK,
>    N_("wall <message>"),
>    N_("Send message to all connections."),
>    N_("For each connected client, pops up a window showing the message "
>       "entered.")
>    wall_cmd
>   },
>   /* ... */
> }

So you want to replace the switch statement in handle_stdin_input? Ok
with me.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "Transported to a surreal landscape, a young girl kills the first woman
  she meets and then teams up with three complete strangers to kill again."
    -- TV listing for the Wizard of Oz in the Marin Independent Journal


[Prev in Thread] Current Thread [Next in Thread]