[GRASS-dev] Shell scripts

GRASS GRASS developer
1

The following shell scripts are still being installed in GRASS 7:

etc/Init.sh
etc/gui/scripts/d.path.sh
etc/prompt.sh
etc/wxpython/scripts/p.rast
etc/wxpython/scripts/p.cmd
etc/wxpython/scripts/p.mon
etc/wxpython/scripts/p.db
etc/wxpython/scripts/p.vect
bin/nviz

etc/Init.sh should probably remain as a fallback in case Python isn't
installed (it's called from grass70.sh, which is installed in e.g.
/usr/local/bin).

etc/prompt.sh could be converted or could remain as a shell script.
It's only used in conjunction with bash.

bin/nviz should be redundant once the Tcl/Tk NVIZ is replaced with the
wxPython version, but that may take a while.

The remaining question is whether d.path.sh and the p.* scripts should
be converted to Python or removed. I don't think that d.path.sh works
with the GUI. The p.* scripts appear to be an attempt to implement
d.mon-like behaviour for the GUI, but I don't know whether this is
functional.

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

2

On Wed, Nov 25, 2009 at 12:33 AM, Glynn Clements
<glynn@gclements.plus.com> wrote:

The following shell scripts are still being installed in GRASS 7:

etc/Init.sh
etc/gui/scripts/d.path.sh
etc/prompt.sh
etc/wxpython/scripts/p.rast
etc/wxpython/scripts/p.cmd
etc/wxpython/scripts/p.mon
etc/wxpython/scripts/p.db
etc/wxpython/scripts/p.vect
bin/nviz

etc/Init.sh should probably remain as a fallback in case Python isn't
installed (it's called from grass70.sh, which is installed in e.g.
/usr/local/bin).

etc/prompt.sh could be converted or could remain as a shell script.
It's only used in conjunction with bash.

[...and useful IMHO]

bin/nviz should be redundant once the Tcl/Tk NVIZ is replaced with the
wxPython version, but that may take a while.

The remaining question is whether d.path.sh and the p.* scripts should
be converted to Python or removed. I don't think that d.path.sh works
with the GUI. The p.* scripts appear to be an attempt to implement
d.mon-like behaviour for the GUI, but I don't know whether this is
functional.

The p.* scripts are semi-functional and should be rewritten to Python.
Not having d.mon/d.rast/d.vect/d.zoom commands is for me, Helena, others
the obstacle to not use GRASS 7 as primary version.
Since the needed (wx)GUI pieces are there, I still hope that someone skilled
is rewriting it in Python. For us it is essential to continue with command line
in GRASS 7.

thanks
Markus

3

Markus Neteler wrote:

> The remaining question is whether d.path.sh and the p.* scripts should
> be converted to Python or removed. I don't think that d.path.sh works
> with the GUI. The p.* scripts appear to be an attempt to implement
> d.mon-like behaviour for the GUI, but I don't know whether this is
> functional.

The p.* scripts are semi-functional and should be rewritten to Python.
Not having d.mon/d.rast/d.vect/d.zoom commands is for me, Helena, others
the obstacle to not use GRASS 7 as primary version.
Since the needed (wx)GUI pieces are there, I still hope that someone skilled
is rewriting it in Python. For us it is essential to continue with command line
in GRASS 7.

d.rast and d.vect haven't gone anywhere.

If you want to be able to control the GUI from the command line, that
should be dealt with as an infrastructure issue, not by creating
wrappers around individual commands.

I can deal with the display/driver libraries, and with generic Python
IPC, but some of it will need the involvement of someone who
understands the GUI.

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

4

Markus Neteler wrote:

> The remaining question is whether d.path.sh and the p.* scripts should
> be converted to Python or removed. I don't think that d.path.sh works
> with the GUI. The p.* scripts appear to be an attempt to implement
> d.mon-like behaviour for the GUI, but I don't know whether this is
> functional.

The p.* scripts are semi-functional and should be rewritten to Python.
Not having d.mon/d.rast/d.vect/d.zoom commands is for me, Helena, others
the obstacle to not use GRASS 7 as primary version.
Since the needed (wx)GUI pieces are there, I still hope that someone skilled
is rewriting it in Python. For us it is essential to continue with command line
in GRASS 7.

So now we have both shell and python versions, and still no actual
explanation.

AFAICT, the GUI has a mode where writing commands to the file
specified by the GRASS_PYCMDFILE GRASS variable will cause them to be
picked up by the GUI, right?

In which case, wouldn't a more useful approach be to extend
R_open_driver() with e.g.:

  const char *cmdfile = G__getenv("GRASS_PYCMDFILE");
  if (cmdfile) {
      FILE *fp = fopen(cmdfile, "a");
      if (fp) {
          fprintf(fp, "%s\n", G_recreate_command());
          exit(0);
      }
  }

so that you can automatically redirect all d.* commands to the GUI?

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

5

Glynn,

Current python implementation is not meant to be a permanent solution
because we cannot just write a python wrapper for every single display
command (including new ones). Shell versions didn't work correctly
either because of wrong command lines they write to GRASS_PYCMDFILE or
the bug in the GUI that I've fixed.

What the new python scripts do is to append d.* command lines to
GRASS_PYCMDFILE. Then, the GUI picks up the file and renders new
images. Your suggestion should work fine and looks very useful. One
concern is that not all d.* commands render on the GUI (e.g., d.font,
d.fontlist). However, this can be taken care of in the GUI, I think.

I vote for extending R_open_driver().

Huidae

On Sat, Dec 05, 2009 at 10:20:08AM +0000, Glynn Clements wrote:

Markus Neteler wrote:

> > The remaining question is whether d.path.sh and the p.* scripts should
> > be converted to Python or removed. I don't think that d.path.sh works
> > with the GUI. The p.* scripts appear to be an attempt to implement
> > d.mon-like behaviour for the GUI, but I don't know whether this is
> > functional.
>
> The p.* scripts are semi-functional and should be rewritten to Python.
> Not having d.mon/d.rast/d.vect/d.zoom commands is for me, Helena, others
> the obstacle to not use GRASS 7 as primary version.
> Since the needed (wx)GUI pieces are there, I still hope that someone skilled
> is rewriting it in Python. For us it is essential to continue with command line
> in GRASS 7.

So now we have both shell and python versions, and still no actual
explanation.

AFAICT, the GUI has a mode where writing commands to the file
specified by the GRASS_PYCMDFILE GRASS variable will cause them to be
picked up by the GUI, right?

In which case, wouldn't a more useful approach be to extend
R_open_driver() with e.g.:

  const char *cmdfile = G__getenv("GRASS_PYCMDFILE");
  if (cmdfile) {
      FILE *fp = fopen(cmdfile, "a");
      if (fp) {
          fprintf(fp, "%s\n", G_recreate_command());
          exit(0);
      }
  }

so that you can automatically redirect all d.* commands to the GUI?

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

6

Huidae Cho wrote:

What the new python scripts do is to append d.* command lines to
GRASS_PYCMDFILE. Then, the GUI picks up the file and renders new
images. Your suggestion should work fine and looks very useful. One
concern is that not all d.* commands render on the GUI (e.g., d.font,
d.fontlist). However, this can be taken care of in the GUI, I think.

d.font is pointless in 7.0; it sets the font and encoding (which only
persists for the duration of the d.font command) then terminates. ISTR
that it was retained for the benefit of code which uses "d.font -l"
(which should migrate to using d.fontlist instead).

There wouldn't be any point in running either d.font or d.fontlist
when GRASS_PYCMDFILE is in effect, although both will actually
generate a blank image in $GRASS_PNGFILE (anything which calls
D_close_driver() will do so).

While we're on this subject:

It would be more convenient for command-line use if many of the
environment variables used by the display architecture were $GISRC
variables, as they could then be modified by commands. E.g. you could
have a d.font script which uses g.gisenv to set the GRASS_FONT and
GRASS_ENCODING variables. Similarly for d.frame.

However, it would probably be less convenient for the GUI, as it would
need to write out a new $GISRC file for each d.* command.

One solution would be to check for an environment variable, and fall
back to using a $GISRC variable if no environment variable is found.
However, if a variable somehow gets set in the environment, the
corresponding $GISRC variables would stop working, which may be
confusing for the user.

Another solution would be to check for a $GISRC variable, and fall
back to using an environment variable if no $GISRC variable is found.
The main problem here is that it would force the GUI to maintain a
separate $GISRC (although that may already be necessary; how does the
GUI cope if the user runs g.mapset from the command-line?).

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

7

The p.* scripts are semi-functional and should be rewritten to Python.
Not having d.mon/d.rast/d.vect/d.zoom commands is for me, Helena, others
the obstacle to not use GRASS 7 as primary version.
Since the needed (wx)GUI pieces are there, I still hope that someone skilled
is rewriting it in Python. For us it is essential to continue with command line
in GRASS 7.

What about adding a IPython-like interactive console?
IPython has history, tab-completion and is emeddable.

8

2009/12/6 Tim Michelsen <timmichelsen@gmx-topmail.de>:

The p.* scripts are semi-functional and should be rewritten to Python.
Not having d.mon/d.rast/d.vect/d.zoom commands is for me, Helena, others
the obstacle to not use GRASS 7 as primary version.
Since the needed (wx)GUI pieces are there, I still hope that someone skilled
is rewriting it in Python. For us it is essential to continue with command line
in GRASS 7.

What about adding a IPython-like interactive console?
IPython has history, tab-completion and is emeddable.

btw, tab-completation for GRASS commands is partly implemented in 6.5+
(see gui/wxpython/gui_modules/prompt.py).

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa