getopts: handling of embedded `=` differs for `--name string` and `--name=string`

[pnkfelix]

Sample program:

extern crate getopts;
use getopts::{optopt,optflagopt,getopts};
use std::os;

fn main() {
    let args = os::args();
    let opts =
        [optopt(    "o", "output", "set output file name", "NAME"),
         optflagopt("a", "attrib", "set attribute", "KEY=VALUE")];
    let matches = match getopts(args.tail(), opts) {
        Ok(m) => { m }
        Err(f) => { fail!(f.to_err_msg()) }
    };
    let output = matches.opt_str("o");
    let keyval = matches.opt_str("a");

    println!("output: {}", output);
    println!("attrib: {}", keyval);
}

Here is a transcript illustrating some interesting invocations

% rustc /tmp/g.rs
% ./g --output=hm
output: Some(hm)
attrib: None
% ./g --attrib
output: None
attrib: None
% ./g --attrib hi
output: None
attrib: Some(hi)
% ./g --attrib hi=world
output: None
attrib: Some(hi=world)
% ./g -a=hi=world
output: None
attrib: Some(=hi=world)
% ./g -a hi=world
output: None
attrib: Some(hi=world)
% ./g --attrib=hi=world
output: None
attrib: Some(hi)
% 

I think that --attrib hi=world and --attrib=hi=world should be treated as equivalent inputs.

From skimming getopts, this should be relatively easy to fix by replacing the call to split('=') with splitn('=', 1).

[pnkfelix]

(technically I guess this would be considering a "breaking-change", since it would be changing the semantics of how getopt behaves in this corner case; though it seems like anyone relying on the current behavior is asking for trouble...)

[steveklabnik]

This issue has been moved to the getopts repo: rust-lang/getopts#14