[GRASS5] Wish: wildcards in command line

GRASS GRASS developer
1

Dear developers,

a "problem" I regularly face (and my students...) is that you
can't use wildcards in GRASS/cmd line.

Suppose you want to patch 20 adjacent images or DEMs, you
have to specify all the names on command line. It would
be great to have:

r.patch in="dem*" out=mybigdem

Or:
g.remove rast="*"

I am dreaming of such a feature since years... :slight_smile:
Do you consider this is feasible (Obviously the parser would
need to be modified).

Just an idea...

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

2

Sounds like a cool feature. See "man glob" for the "standard"
pathname matching function (I have it here on Linux and IRIX).

Markus Neteler wrote:

Dear developers,

a "problem" I regularly face (and my students...) is that you
can't use wildcards in GRASS/cmd line.

Suppose you want to patch 20 adjacent images or DEMs, you
have to specify all the names on command line. It would
be great to have:

r.patch in="dem*" out=mybigdem

Or:
g.remove rast="*"

I am dreaming of such a feature since years... :slight_smile:
Do you consider this is feasible (Obviously the parser would
need to be modified).

Just an idea...

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

--
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+
| Eric B. Mitchell mailto:emitchell@altaira.com |
| tel: (301) 809 - 3534 Altair Aerospace Corporation |
| tel: (800) 7 - ALTAIR 4201 Northview Dr. Suite 410 |
| fax: (301) 805 - 8122 Bowie, MD 20716 |
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+
              ,___
          /"\ / o=\ /"""---===/
         / \_/ \__/ ---===/
         | //\ || /""TT""/ //\ || ||""\
         | // \ || || // \ || ||__/
         | //--==\ |L--/ || //--==\ || || "=,
          \ ---===/
           \____---===/

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

3

On Thu, Sep 21, 2000 at 06:28:45PM +0100, Markus Neteler wrote:

a "problem" I regularly face (and my students...) is that you
can't use wildcards in GRASS/cmd line.

Suppose you want to patch 20 adjacent images or DEMs, you
have to specify all the names on command line. It would
be great to have:

r.patch in="dem*" out=mybigdem

Or:
g.remove rast="*"

I am dreaming of such a feature since years... :slight_smile:
Do you consider this is feasible (Obviously the parser would
need to be modified).

Hmm I do not think it is a good idea to add this capabiltiy to
each grass command. Actually, this only works with unix commands,
because they already can accept mutliple arguments (like rm).
A start would be to add wildcards to g.list and maybe a flag
to produce a comma seperated list.

r=`g.list -l type=r dem*`
echo $r
dem1 dem2 dem3
r.patch in=$r out=mybigdem

In the case of r.patch and g.remove, we could add the functions,
reading the files from a file, making it even simpler.

g.list type=r dem* | r.patch inlist=- out=mybigdem

This would be unix tradition.

I would be interested to know how many commands actually do
need more than one or two map parameters from the same type.

  Bernhard

--
Professional Service around Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)

4

I have been a list lurker for some time, but now, maybe to the chagrin
of some, I have decided to participate.

I have a couple of ideas that I would like to propose. If you wish,
these are my grass cuttings. =:-)

1) Separation of the code from the interface.
Each program has the interface built into it. What I propose is
something like sci (SCreen Input at http://linuxparts.com/software.html
) where the interface is held separate from the code. Even though sci
might work unchanged with GRASS, I propose HTML (or XML?) as the
interface language instead of YAF (yet another format). It would work
something like this:

call html_interface passing name of html file to use
html_interface would do the following:
  parse the html
  create interface based on FORM tags
  fill some of the interface with information (like a pop-up list of
existing raster files)
  return information from filled out form, variable names would be based
on the NAME=var in the HTML, or just var1, var2, ...etc.

I was hoping to create an example, but my C coding skills are too
primitive.

ADVANTAGES:
Trivial internationalization, just replace the HTML with German, or
French, or ?. Of course the html_interface would have to understand how
to parse and properly display the HTML.

Programming would be easier, you just make one call, instead of the
series of calls made now.

A bunch of people can write HTML.

An interface could be built, based on the HTML files, in any programming
language.

Potential integration with the help in HTML.

Users could customize the interface, add notes, comments, or gotchas by
editing the HTML files.

Could be extended to include error messages (see number 2), mini helps
or howtos,...etc.

DISADVANTAGES:
Bunch o'work.

2) Error messages with help
It would be fantastic to have guidance about what to do after the error
message. For example, 'rast_reclass' is a r.reclass version of 'rast'.
If a user attempts an operation on 'rast_reclass' that requires _real_
raster data, the error message should say something like:

  In order to use ? command with rast_rescale, create new raster data
with
  > r.mapcalc new_raster=rast_rescale

followed by an option to take you to help.

This would fit in nicely with number 1 because a error message could be
shared among programs.

3) Move GRASS development to Sourceforge - http://sourceforge.net/
Marcus Neteler has mentioned at least twice about the amount of time
that he spends tracking bugs. Sourceforge offers CVS repository, bug
tracking, mailing lists, web space,...etc. all for free.

4) All monitors should be stopped automatically if you quit GRASS, or at
least ask if you want to stop all monitors. I am always starting GRASS
up again to stop monitors.

5) Expose the data structures to a scripting language. Something similar
has been done with MapServer ( http://mapserver.gis.umn.edu/index.html )
called MapScript.

Well, how was that for a first post? Don't reconfigure your trash
filters yet, I can only get better, maybe. =:-)

take care
tim cera

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

5

On Fri, Sep 22, 2000 at 06:54:57PM -0500, Tim Cera wrote:

3) Move GRASS development to Sourceforge - http://sourceforge.net/
Marcus Neteler has mentioned at least twice about the amount of time
that he spends tracking bugs. Sourceforge offers CVS repository, bug
tracking, mailing lists, web space,...etc. all for free.

SourceForge isn't the solution to everything though. For very large
projects, the bug tracking might not scale well, however a recent change
was made that allows bulk updating of bug status.

In the case of one of the Open Source projects that I lead, Netrek, we
chose to adopt SourceForge for bug tracking but leave the CVS repository
in the same place it was before. Insufficient reason to move, and the
service from the current place is better; 24x7 pager support.

So there is no reason to move _everything_.

It would be purely up to Marcus, in my humble opinion.

Perhaps a Marcus-local instance of SourceForge software?

--
James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

6

Hi Tim

Tim Cera wrote:

1) Separation of the code from the interface.

I have already started taking steps to do this. But my proposal will
allow any interface to be used, including HTML. Basically when a grass
program needs to print or input data, it does so through a generic
function call. That function call checks which interface is being used
and then calls the appropriate function in the interface code. If you
want a specific interface, you only need to code the interface
functions. You would not have to touch any Grass core functions.

I am only doing a small part of this. As you say, it will take a lot of
work to do all of grass. But at least I will provide a model that others
can follow.

4) All monitors should be stopped automatically if you quit GRASS, or
at least ask if you want to stop all monitors.

This already exists in tcltkgrass under the quit menu item.

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

7

On Sun, Sep 24, 2000 at 11:21:10PM +1100, James Cameron wrote:

On Fri, Sep 22, 2000 at 06:54:57PM -0500, Tim Cera wrote:
> 3) Move GRASS development to Sourceforge - http://sourceforge.net/
> Marcus Neteler has mentioned at least twice about the amount of time
> that he spends tracking bugs. Sourceforge offers CVS repository, bug
> tracking, mailing lists, web space,...etc. all for free.

Actually, we do have all these things.
Markus spends his time in fixing the bugs
not in the maintaining the bug list.

We decided that it would be less work to not have the overhead of
a bug tracking for now. We might decide otherwise in the future,
and then we add bug tracking.

SourceForge isn't the solution to everything though. For very large
projects, the bug tracking might not scale well, however a recent change
was made that allows bulk updating of bug status.

In the case of one of the Open Source projects that I lead, Netrek, we
chose to adopt SourceForge for bug tracking but leave the CVS repository
in the same place it was before. Insufficient reason to move, and the
service from the current place is better; 24x7 pager support.

So there is no reason to move _everything_.

It would be purely up to Marcus, in my humble opinion.

Perhaps a Marcus-local instance of SourceForge software?

This might be interesting.
Up to now we thing that local development resources
(University of Hannover& Intevation) are better under
our control and scale better.

As for moving to sourceforge I do not really like the dependency of
a lot of Free Software Projects on one spot. The sourceforge
privacy policy also was not in place for quite a while (IIRC).

  Bernhard

--
Professional Service around Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)

8

Justin Hickey wrote:

Hi Tim

Tim Cera wrote:
> 1) Separation of the code from the interface.

I have already started taking steps to do this. But my proposal will
allow any interface to be used, including HTML. Basically when a grass
program needs to print or input data, it does so through a generic
function call. That function call checks which interface is being used
and then calls the appropriate function in the interface code. If you
want a specific interface, you only need to code the interface
functions. You would not have to touch any Grass core functions.

I am only doing a small part of this. As you say, it will take a lot of
work to do all of grass. But at least I will provide a model that others
can follow.

You are describing the internal workings to choose differently coded
interfaces. What I proposed is that the interface is not in any
compiled code at all, anywhere. The interface would be in text files
that the user can edit, and change the interface without re-compiling
the program or knowing any C. In effect, the interface is written in an
interpreted display language. HTML I think would be a good choice
because it is so common (though it doesn't have a table input type), but
a new language could be made up to suit, like what the sci (
http://linuxparts.com/software.html ) developer did.

take care
tim cera

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

9

Hello Tim

Tim Cera wrote:

You are describing the internal workings to choose differently coded
interfaces. What I proposed is that the interface is not in any
compiled code at all, anywhere. The interface would be in text files
that the user can edit, and change the interface without re-compiling
the program or knowing any C.

take care
tim cera

Hmmm. I'm still having problems understanding how this would work. As
far as I know (my knowledge may be limited here since I am not familiar
with many of the recent changes to HTML - dynamic HTML and style
sheets), HTML does not have a mechanism for interfacing with C code
applications. That is, passing the applications various data, and
receiving various information from a C program and displaying it to a
user. For example if one of the grass programs generates an error, how
does the error message (handled by the G_fatal_error() function) get
passed to HTML so that it can pop up a window to present the message?
This is what I don't understand.

In effect, the interface is written in an interpreted display
language.

This is what Tcl/Tk is. But unlike HTML, Tcl/Tk has a mechanism for
interfacing with compiled C applications. The work that I will do will
put all the interface generation code in Tcl/Tk scripts that will (just
like your HTML version) be in text files that users can edit. Isn't this
what you are suggesting only I am using Tcl/Tk instead of HTML? I don't
see how our proposals are different except for the choice in GUI
language.

but a new language could be made up to suit, like what the sci (
http://linuxparts.com/software.html ) developer did.

I'm sorry but that page does not describe what the author did and I do
not have time to go through the source code. Could you please post a
summary of what this package does in terms of creating a GUI and
interfacing it with an application?

Maybe I'm missing something, but I just don't see the difference in our
proposals. I don't see how you can avoid the mechanism that connects the
GUI to the application (the generic functions I talked about in my last
post).

--

Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

10

> In effect, the interface is written in an interpreted display
> language.

This is what Tcl/Tk is. But unlike HTML, Tcl/Tk has a mechanism for
interfacing with compiled C applications. The work that I will do will
put all the interface generation code in Tcl/Tk scripts that will (just
like your HTML version) be in text files that users can edit. Isn't this
what you are suggesting only I am using Tcl/Tk instead of HTML? I don't
see how our proposals are different except for the choice in GUI
language.

Maybe they are identical, it depends on one thing: will the curses
interface use your Tcl/Tk scripts to build the curses interface
screens? What I was thinking about is a separate file that describes
the dialog (maybe that is a better word?) that would be used by all
interfaces; curses, Tcl/Tk, web ...etc. For example, the following
would be a HTML file describing the dialog for r.in.dem. Notice that
there is no programming inherent in HTML that would link it to the grass
program (except maybe the ACTION command?). The HTML would simply be
used, by whatever interface system, to display the dialog on the screen.

<HTML>
<HEAD>
<TITLE>r.in.dem - Import a DEM (Digital Elevation Model).
</TITLE>
</HEAD>
<BODY>
<FORM METHOD=POST ACTION="r.in.dem">
Input file name: <INPUT TYPE=text NAME="filename" SIZE=32
MAXLENGTH=80><P>
Output raster map name: <INPUT TYPE=text NAME="outfilename"><P>
Spheroid: <SELECT NAME="spheroid">
                          <OPTION VALUE="sphere">sphere
                          <OPTION VALUE="APL4.9">APL4.9
                          <OPTION VALUE="CPM">CPM
                          <OPTION VALUE="GRS67">GRS67
                          <OPTION VALUE="IAU76">IAU76
                          <OPTION VALUE="MERIT">MERIT
                          <OPTION VALUE="SEasia">SEasia
                          <OPTION VALUE="...etc."> I didn't want to type
them all :slight_smile:
                        </SELECT><P>
Resolution: East/West <INPUT TYPE=text NAME="ew_res"><P>
Resolution: North/South <INPUT TYPE=text NAME="ns_res"><P>
Size: Rows: <INPUT TYPE=test NAME="rows"><P>
Size: Columns: <INPUT TYPE=test NAME="columns"><P>
<INPUT TYPE=submit><P>
A typical 7.5 minute U.S.G.S DEM has ? rows, ? columns and a uniform
resolution of ?. I am making this section up. The point is that you
could have help, notes, hints,...etc. Also a <A
HREF="r.in.dem.html">link to the HTML help.</A>
</FORM>
</BODY>
</HTML>

That's it. The interface system (curses, Tcl/Tk, ...whatever) would be
responsible for parsing, display, and collection of user inputs.

Now, the problems that have cropped up as I have thought about this.
How do you handle input sanity checks? With a web browser you use
JavaScript which would be much too big. I have thought of a couple
other ways, but none of them elegant. What about large tables, like
what happens with r.reclass? No solution to that either. Maybe XML
would be a better dialog builder?

Anyway, that is one of the things that I was thinking about.

take care
tim cera

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

11

Yes, XML would be better for such a beast. In theory, you could write
XSLT scripts to translate the XML into targets usable by whatever.

You might be interested in entity http://entity.evilplan.org/ . It's
currently hooked up with C, perl, and python. It is rather new code,
but looks very interesting.

--
/bin/sh ~/.signature:
Command not found

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

12

Hello Tim

Tim Cera wrote:

Maybe they are identical, it depends on one thing: will the curses
interface use your Tcl/Tk scripts to build the curses interface
screens? What I was thinking about is a separate file that describes
the dialog (maybe that is a better word?) that would be used by all
interfaces; curses, Tcl/Tk, web ...etc.

Ahh! OK, I understand what you are proposing. You are basically going
one step further than I am.

That's it. The interface system (curses, Tcl/Tk, ...whatever) would
be responsible for parsing, display, and collection of user inputs.

Let me see if I got it this time. Your proposal is to create a single
document for each interface dialog which would contain all the static
entities for said dialog. Then a parser for a particular GUI will read
this file and create the appropriate interface dialog. Is that right?

Now, the problems that have cropped up as I have thought about this.
How do you handle input sanity checks? With a web browser you use
JavaScript which would be much too big. I have thought of a couple
other ways, but none of them elegant. What about large tables, like
what happens with r.reclass? No solution to that either. Maybe XML
would be a better dialog builder?

Yes, as Eric suggested XML or SGML would be the tool to use to implement
your proposal. As for sanity checking, the place to put that is in
whatever program is called when you click OK. If this is written in C
then you don't need anything like Javascript. Yes, it would be nice to
do sanity checks on the fly, but the data has to be passed to a C
function eventually to get to GRASS, so the sanity check might as well
be a C function as well. That way all interfaces use the same sanity
checks.

Interesting idea, and it would probably be nice to have, however, as you
said in your first post, it would be a lot of work.

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'