On Sun, Jun 29, 2014 at 10:00 AM, Huidae Cho <[email protected]> wrote:
> 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. > > 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? > A lot of questions would arise such as `--option=value` or `--option value` or both or what about --overwrite and short flags and what about backwards compatibility and (visual) compatibility with Python. I'm not sure how this is real but it is not a bad idea to follow this practice. I even better idea to be prepared for that. > 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. > Hm, I would not think about @ but it might actually be pretty good. People sometimes write email addresses by hand, so they should have an idea how to write @ at their national keyboard. Also @ is related to location in GRASS, and default region is default region for location, so there is some connection. > On Jun 29, 2014 8:19 AM, "Glynn Clements" <[email protected]> > wrote: > >> >> Vaclav Petras wrote: >> >> > I think that the default interpretation of * is all, so * can be >> confused >> > with the default for this option (all). >> >> There's also the issue that the shell will perform wildcard expansion. >> >> This probably doesn't directly matter unless you have files named >> "region=<something>" in the current directory. >> >> But users might spend time worrying about how to quote/escape it >> without realising that it won't matter. >> >> It might matter for the GUI, if its command-line handling doesn't >> exactly mirror the shell's rules. >> >> It might matter for shell scripts if the option's value is ever >> separated from the region=part. >> >> It would matter if we ever wanted to support the more conventional >> "--option value" getopt syntax. >> >> If the current region is selected with ".", maybe ".." for the default >> region? Or even "DEFAULT" (that would preclude using a named region >> with that name; but is that likely?). >> >> -- >> Glynn Clements <[email protected]> >> >
_______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
