[Toybox] toybox - added cmp

[Rob Landley]

On 02/06/2012 04:11 AM, Tim Elliott wrote:
>   * Doesn't throw an error if both -s and -l are used. SUSv4 is
> ambiguously ambiguous.

Lemme diverge a bit (thinking out loud) into why lib/args.c isn't
flexible enough yet. (You can skip this bit if you don't care.)

At a design level, I need a better way to indicate relationships
_between_ different options. The problem with going:

  x~yy~x

Is that A) it's redundant, B) it's hard to read, C) it's not quite fully
implemented anyway.

In theory it means "when x happens turn off y, when y happens turn off
x."  "x" is a command line option, "~y" is an option to that flag that
disables y, then "y" is another flag, "~x" is an option to that flag
that disables x.

But each letter should only occur once, and bunched up like that you
have to read carefully to see which instances are options and which
aren't.  (Letters that _aren't_ defining an option aren't exactly
ideal.) And the current lib/args.c can't handle forward references, so
x~y won't work because it hasn't seen y yet.  That last bit's just an
implementation detail, but I haven't fixed it yet because I need to
figure out what I want the string to look like.

The parentheses are used for (longopts), but the other grouping
characters are available, so I _think_ what I can do is use {} to
indicate a group, and have an initial character indicating :

  {xy} to say you can only have one item in this group.  But what if
"setting one sets all the others", or "setting one switches off the
others", or "setting more than one is an error"?  Different behaviors
needed, all in the name of "grouping".

The fix: add another punctuation character at the start of the group
specifying how to treat the group:

  {-xyz) - turn off other group members (keep last one only)
  {+xyz) - turn on all other group members if you see any of them.
  {!xyz} - Exclusive options, specifying more than one is an error.

The + grouping is only useful if they take extra arguments, maybe one
numeric and another a string or something.  The original idea behind +
was that you could have x automatically switch on y but then y could be
specified without x, a _symmetrical_ grouping is what the others want,
but less useful for the switch-on behavior...  Maybe + there is "if you
see one all the others are _requierd_, error if you didn't see them.
There's a few cases of that.  At runtime I can test
if(flags&(FLAG_a|FLAG_b)) easily enough.)

Really what I'm doing is waiting to see what I need as more commands
come in, and refactoring my existing infrastructure to cleanly handle
what it actually needs to _do_.  (Implementing "infrastructure in search
of a user" is particularly bad form of premature optimization. I often
do redundant implementations of things in various commands and then
factor the common code out, then clean stuff up to be more elegant after
the fact...)

Rob

 1328621398.0