Suggestion for command line parsing

[Jeff Squyres]

The other day, one of our developers accidentally typed the following:

    ./configure ==prefix=foo ...

and since our configure script and build process is pretty long, he  
didn't notice the error until he typed "make install" and it tried to  
install into /usr/local.  Oops!

Granted, this is clearly a user error, but I wonder if a quick test in  
the command line parsing code could have prevented it.  Indeed, if you  
run the above command, you end up with something like this:

-----
$ ./configure ==prefix=foo
./configure: line 2286: ==prefix=foo: command not found
export CVS_RSH="ssh"
export DDT_PROCESS_TIMEOUT="0"
export DUALCASE="1"
...etc.
-----

You can see that an error occurred, and then my entire environment was  
displayed (because a resulting "export $foo" ended up with $foo being  
empty).  IMHO, it would be ok to error out if "=" is the first  
character (especially since the = and - keys are next to each other on  
US keyboards -- it might not be too uncommon of a mistake...?).

I have no idea how the AC code is structured, but the generated code  
in question in configure is the following:

-----
  *=*)
    ac_envvar=`expr "x$ac_option" : 'x\([^=]*\)='`
    # Reject names that are not valid shell variable names.
    expr "x$ac_envvar" : ".*[^_$as_cr_alnum]" >/dev/null &&
      { $as_echo "$as_me: error: invalid variable name: $ac_envvar" >&2
   { (exit 1); exit 1; }; }
    eval $ac_envvar=\$ac_optarg
    export $ac_envvar ;;
-----

So there's already an attempt to reject invalid shell var names.  In  
the ==foo=bar case, $ac_envvar ends up empty (hence the eval errors  
out and the export ends up displaying the current environment).    
Here's a simple addition to the above code that will kick out the  
==foo=bar case, although someone smarter than me with expr can  
probably come up with something better:

-----
    if test -z "$ac_envvar"; then
      $as_echo "$as_me: error: invalid variable name: $ac_option" >&2
      exit 1
    fi
-----

--
Jeff Squyres
Cisco Systems