<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 13, 2015 at 12:14 AM, Justin Bogner <span dir="ltr"><<a href="mailto:mail@justinbogner.com" target="_blank">mail@justinbogner.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":7uf" class="a3s" style="overflow:hidden">FWIW, in my experience very few --option style options require '='. This<br>
is almost always optional and a space is accepted instead.<br></div></blockquote><div><br></div><div>Yes, existing command line tools are shockingly bad at being consistent. It's quite frustrating. Even "simple" commandline interfaces like GNU awk are inconsistent. :: sigh ::</div><div><br></div><div>Anyways, this is part of why I wouldn't suggest consistency as a reason to favor requiring the '='s. I think that requiring the '='s rather than relying on the order of flags is a vastly superior technical approach, especially for a command where we expect complex systems to manage very large numbers of flags composited from many systems (in short, build systems coping with the vagaries of portability across platforms and toolchains). There are too many ways confusion can erupt from an option being separated from its value accidentally. That's my vote anyways, and as you say...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":7uf" class="a3s" style="overflow:hidden">
<br>
That said, we're horribly inconsistent about which option styles we<br>
accept for legacy and compatibility reasons. Adding every possible way<br>
to spell an option will only increase the inconsistency, and I'd really<br>
rather we didn't go there. For our own options we should choose a style<br>
and stick with it.</div></blockquote></div><br>Exactly. Unless there is some strong reason to prefer the syntax without an '='s, I vote we just require it and try to stick to it. =]</div></div>