<p dir="ltr">Unless there are files starting with region= in the current directory, region=* is not expanded (at least in bash). Some modules also use * for a special case and I didn't have an expansion problem with them either.</p>

<p dir="ltr">I think '--option value' is a valid point though. Are we going to ever change option=value to --option value or planning to do so? If so, starting special names with an @ may be a good idea because no element names can start with @ because it's the separator between element names and mapset names.</p>

<div class="gmail_quote">On Jun 29, 2014 8:19 AM, "Glynn Clements" <<a href="mailto:glynn@gclements.plus.com">glynn@gclements.plus.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Vaclav Petras wrote:<br>
<br>
> I think that the default interpretation of * is all, so * can be confused<br>
> with the default for this option (all).<br>
<br>
There's also the issue that the shell will perform wildcard expansion.<br>
<br>
This probably doesn't directly matter unless you have files named<br>
"region=<something>" in the current directory.<br>
<br>
But users might spend time worrying about how to quote/escape it<br>
without realising that it won't matter.<br>
<br>
It might matter for the GUI, if its command-line handling doesn't<br>
exactly mirror the shell's rules.<br>
<br>
It might matter for shell scripts if the option's value is ever<br>
separated from the region=part.<br>
<br>
It would matter if we ever wanted to support the more conventional<br>
"--option value" getopt syntax.<br>
<br>
If the current region is selected with ".", maybe ".." for the default<br>
region? Or even "DEFAULT" (that would preclude using a named region<br>
with that name; but is that likely?).<br>
<br>
--<br>
Glynn Clements <<a href="mailto:glynn@gclements.plus.com">glynn@gclements.plus.com</a>><br>
</blockquote></div>