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

GRASS GIS GRASS GIS developer
1

Hi Huidae,

I think that the default interpretation of * is all, so * can be confused with the default for this option (all). But I don’t have any suggestion of character for default region, perhaps + because is on numeric keyboard, too. Or do you think that this is not an issue since * is in GRASS used also for NULLs?

Thanks,

Vaclav

···

On Sat, Jun 28, 2014 at 10:04 AM, <svn_grass@osgeo.org> wrote:

Author: hcho
Date: 2014-06-28 07:04:42 -0700 (Sat, 28 Jun 2014)
New Revision: 61027

Modified:
grass/trunk/general/g.mlist/main.c
Log:
g.mlist: help cosmetics

Modified: grass/trunk/general/g.mlist/main.c

— grass/trunk/general/g.mlist/main.c 2014-06-28 13:59:27 UTC (rev 61026)
+++ grass/trunk/general/g.mlist/main.c 2014-06-28 14:04:42 UTC (rev 61027)
@@ -115,10 +115,9 @@
opt.separator->answer = “newline”;

opt.region = G_define_standard_option(G_OPT_M_REGION);

  • opt.region->label = _(“Name of saved region for map search”);
  • opt.region->label = _(“Name of saved region for map search (default: not restricted)”);
    opt.region->description =
  • _("‘*’ for default region; ‘.’ for current region "
  • “(default: not restricted)”);
  • _(“‘.’ for current region; ‘*’ for default region”);

opt.output = G_define_standard_option(G_OPT_F_OUTPUT);
opt.output->required = NO;

grass-commit mailing list
grass-commit@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-commit

2

Hi Vaclav,

I never thought that can be confused with the default “not restricted”. I wouldn’t say the default is “all”. The default is “Don’t use any region at all”. Well, maybe, they are the same thing? ‘*’ means the entire region that the PERMANENT mapset supports by default.

We can introduce as many special characters as we want, but IMHO it’s better to keep special characters to a minimum if possible and as long as we clearly convey what they mean, it should be fine.

Best,
Huidae

···

On Sat, Jun 28, 2014 at 3:54 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:

Hi Huidae,

I think that the default interpretation of * is all, so * can be confused with the default for this option (all). But I don’t have any suggestion of character for default region, perhaps + because is on numeric keyboard, too. Or do you think that this is not an issue since * is in GRASS used also for NULLs?

Thanks,

Vaclav

On Sat, Jun 28, 2014 at 10:04 AM, <svn_grass@osgeo.org> wrote:

Author: hcho
Date: 2014-06-28 07:04:42 -0700 (Sat, 28 Jun 2014)
New Revision: 61027

Modified:
grass/trunk/general/g.mlist/main.c
Log:
g.mlist: help cosmetics

Modified: grass/trunk/general/g.mlist/main.c

— grass/trunk/general/g.mlist/main.c 2014-06-28 13:59:27 UTC (rev 61026)
+++ grass/trunk/general/g.mlist/main.c 2014-06-28 14:04:42 UTC (rev 61027)
@@ -115,10 +115,9 @@
opt.separator->answer = “newline”;

opt.region = G_define_standard_option(G_OPT_M_REGION);

  • opt.region->label = _(“Name of saved region for map search”);
  • opt.region->label = _(“Name of saved region for map search (default: not restricted)”);
    opt.region->description =
  • _("‘*’ for default region; ‘.’ for current region "
  • “(default: not restricted)”);
  • _(“‘.’ for current region; ‘*’ for default region”);

opt.output = G_define_standard_option(G_OPT_F_OUTPUT);
opt.output->required = NO;

grass-commit mailing list
grass-commit@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-commit

3

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@gclements.plus.com>

4

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? 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.

On Jun 29, 2014 8:19 AM, “Glynn Clements” <glynn@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=” 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@gclements.plus.com>

5

On Sun, Jun 29, 2014 at 10:00 AM, Huidae Cho <grass4u@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@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@gclements.plus.com>

6

Huidae Cho wrote:

Some modules also use * for a special case and I didn't have an
expansion problem with them either.

AFAIK, all the modules which currently use "*" do so because it's part
of standard glob or regex syntax.

For most utilities, using the shell's wildcard syntax makes the need
for quoting inevitable (e.g. the find(1) manual page explicitly
mentions this in relation to the -name, -iname etc options).

GRASS "gets away with it" because of the option=value syntax and the
fact that "=" is uncommon in filenames.

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?

I doubt that we'd change it in the sense of abandoning support for the
existing syntax, but modifying G_parser() to allow either form
probably wouldn't require much work.

--
Glynn Clements <glynn@gclements.plus.com>

7

On Mon, Jun 30, 2014 at 9:19 AM, Glynn Clements <glynn@gclements.plus.com>
wrote:

Huidae Cho wrote:

> Some modules also use * for a special case and I didn't have an
> expansion problem with them either.

AFAIK, all the modules which currently use "*" do so because it's part
of standard glob or regex syntax.

I still think that I have seen somewhere usage of * in the meaning of NULL
values. But by short search I found only:

r.report
    null String representing no data cell value
           default: *

This is output, so the command line issues are not present, the user
confusion is.

r.mask
  maskcats Raster values to use for mask
              format: 1 2 3 thru 7 *
             default: *

Manual does not say what * means. r.mask is using r.reclass, so if my
understanding is correct * should mean all remaining values but then the
format example does not make sense (or perhaps it does as a format
description, but not as an example).

For most utilities, using the shell's wildcard syntax makes the need

for quoting inevitable (e.g. the find(1) manual page explicitly
mentions this in relation to the -name, -iname etc options).

GRASS "gets away with it" because of the option=value syntax and the
fact that "=" is uncommon in filenames.

> 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?

I doubt that we'd change it in the sense of abandoning support for the
existing syntax, but modifying G_parser() to allow either form
probably wouldn't require much work.

--
Glynn Clements <glynn@gclements.plus.com>
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

8

Hmm… v.out.ascii also uses * for all columns and g.mlist uses * for all mapsets and DEFAULT_WIND. I don’t know why I thought there are “many” modules that use *.

···

On Mon, Jun 30, 2014 at 9:36 AM, Vaclav Petras <wenzeslaus@gmail.com> wrote:

On Mon, Jun 30, 2014 at 9:19 AM, Glynn Clements <glynn@gclements.plus.com> wrote:

Huidae Cho wrote:

Some modules also use * for a special case and I didn’t have an
expansion problem with them either.

AFAIK, all the modules which currently use “*” do so because it’s part
of standard glob or regex syntax.

I still think that I have seen somewhere usage of * in the meaning of NULL values. But by short search I found only:

r.report

null String representing no data cell value
default: *

This is output, so the command line issues are not present, the user confusion is.

r.mask
maskcats Raster values to use for mask
format: 1 2 3 thru 7 *
default: *

Manual does not say what * means. r.mask is using r.reclass, so if my understanding is correct * should mean all remaining values but then the format example does not make sense (or perhaps it does as a format description, but not as an example).

For most utilities, using the shell’s wildcard syntax makes the need
for quoting inevitable (e.g. the find(1) manual page explicitly
mentions this in relation to the -name, -iname etc options).

GRASS “gets away with it” because of the option=value syntax and the
fact that “=” is uncommon in filenames.

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?

I doubt that we’d change it in the sense of abandoning support for the
existing syntax, but modifying G_parser() to allow either form
probably wouldn’t require much work.

–
Glynn Clements <glynn@gclements.plus.com>

grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev