[GRASS-dev] [GRASS-SVN] r61027 - grass/trunk/general/g.mlist

[Vaclav Petras]

On Sun, Jun 29, 2014 at 10:00 AM, Huidae Cho <grass4u at gmail.com> 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" <glynn at gclements.plus.com>
> 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 <glynn at gclements.plus.com>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20140629/d77691be/attachment.html>