[GRASS5] Darwin Pre1 gtty stty errors

GRASS GRASS developer
1

Back on Wed, 6 Dec 2000, Eric Miller wrote regarding [GRASS5] _gtty & _stty errors:

On Wed, Dec 06, 2000 at 03:31:57PM -0800, Jeshua Lacock wrote:
... snip ...

Ok, I installed the libncurses 5.2 and it appears that they were already installed because modules that compiled before gave a error stating that "/usr/lib/libncurses.a is out of date; rerun ranlib(1)". After updating with ranlib the modules that worked before now work, however, I still get the errors with the above modules:

   /usr/bin/ld: Undefined symbols:
   _gtty
   _stty

Which leads me to believe that they must be defined somewhere else.... Where??

I would really like to figure this one out as it will fix 6 modules....

Well, not sure where those get defined, but I find "gtty" and "stty" in
libc.a. I couldn't find those symbols in libncurses.a, libcurses.a, or
libtermcap.a -- sorry for the red herring. You can use "nm
/path/to/staticlib.a | grep '<symbol>'" to hunt for where symbols are
defined. See if libc.a has 'stty' (it probably does). Are you using
the --with-USE_TERMIO directive? If not, maybe it's worth a try.

I was not able to find the symbols in libc.a after I installed the Darwin static c library (Libc). I also ran configure with the TERMIO directive.

And on Sat, 9 Dec 2000, Eric Miller wrote:

On Sat, Dec 09, 2000 at 06:52:48PM -0800, Jeshua Lacock wrote:

OK, I'm back after re-installing my system.

It appears that gtty and stty are defined in the header libc.h (which
is on my system), however I cannot locate the archive libc.a anywhere
on my system. I suspect that this may be the problem, can someone
confirm this?

Does anyone know where to get libc.a? Would it work if someone
emailed it to me (off list, of course)?

You need to get a copy of the static C library for Mac OS X. Possibly
available in developer's resources or some such. Apparently you only
have the shared libes ?? (libc.so or libc.o). It's likely much to big
to mail and it *must* be built for that system. Mine weighs in around
2.5 MB.

I successfully installed the Darwin static c library (Libc), and I still get the gtty & stty errors. Apparently, gtty and stty have been made obsolete by ioctl().

I quote Cornell's web page:

"______
These subroutines have been made obsolete by the ioctl subroutine.

The stty subroutine sets the state of the terminal associated with the FileDescriptor parameter. The gtty subroutine retrieves the state of the terminal associated with FileDescriptor. To set the state of a terminal, the calling process must have write permission.

Use of the stty subroutine is equivalent to the ioctl (FileDescriptor, TIOSETP, Buffer) subroutine, while use of the gtty subroutine is equivalent to the ioctl (FileDescriptor, TIOGETP, Buffer) subroutine.
" ---------

The complete URL is at:

  http://nim.cit.cornell.edu/usr/share/man/info/en_US/a_doc_lib/libs/basetrf2/
stty.htm

So should I try and replace the calls myself, or would someone be willing to help? An ideal simple test module that has this problem it d.colors.

BTW: pre1 compiled well for me, these are the main modules that failed. So if we can kick this one in the butt, Grass will be nearly 100% complete on Mac OS X.

Thanks,

Jeshua Lacock
Cartographer/Owner
http://SierraMaps.com
http://3dTopoMaps.com
Telephone: (760) 935-4481

2

Jeshua Lacock wrote:

I successfully installed the Darwin static c library (Libc), and I still
get the gtty & stty errors. Apparently, gtty and stty have been made
obsolete by ioctl().

I quote Cornell's web page:

"______
These subroutines have been made obsolete by the ioctl subroutine.

The stty subroutine sets the state of the terminal associated with the
FileDescriptor parameter. The gtty subroutine retrieves the state of the
terminal associated with FileDescriptor. To set the state of a terminal,
the calling process must have write permission.

Use of the stty subroutine is equivalent to the ioctl (FileDescriptor,
TIOSETP, Buffer) subroutine, while use of the gtty subroutine is
equivalent to the ioctl (FileDescriptor, TIOGETP, Buffer) subroutine.
" ---------

The complete URL is at:

http://nim.cit.cornell.edu/usr/share/man/info/en_US/a_doc_lib/libs/basetrf2/
stty.htm

So should I try and replace the calls myself, or would someone be
willing to help? An ideal simple test module that has this problem it
d.colors.

The current implementation of d.colors uses the TCGETA/TCSETAW
ioctl()s if HAVE_TERMIO_H is defined and stty()/gtty() otherwise. If
you're getting errors regarding stty() or gtty(), then it appears that
configure hasn't detected the <termio.h> header.

However, the ioctl()s themselves have been superseded by the POSIX.1
tcgetattr() and tcsetattr() functions.

A more significant "however" is that d.colors/tty.c is redundant; the
only functions which are used are Get_old_tty() and Get_new_tty().
These store the terminal settings before and after curses
initialisation. But the stored settings are never used, i.e. neither
Old_tty() nor New_tty() are called.

I will commit a fix which removes this code, which should eliminate
any portability considerations altogether. If you know of any other
programs which do this, let me know.

--
Glynn Clements <glynn.clements@virgin.net>

3

On Monday, June 4, 2001, at 06:21 PM, Glynn Clements wrote:

I will commit a fix which removes this code, which should eliminate
any portability considerations altogether. If you know of any other
programs which do this, let me know.

Hi again,

I neglected to mention in my last post that two additional modules, i.class and i.ortho.photo, fails with the gtty & stty errors as well.

Thanks again,

Jeshua Lacock
Cartographer/Owner
http://SierraMaps.com
http://3dTopoMaps.com
Telephone: (760) 935-4481

4

Jeshua Lacock wrote:

>> So should I try and replace the calls myself, or would someone be
>> willing to help? An ideal simple test module that has this problem it
>> d.colors.
>
> The current implementation of d.colors uses the TCGETA/TCSETAW
> ioctl()s if HAVE_TERMIO_H is defined and stty()/gtty() otherwise. If
> you're getting errors regarding stty() or gtty(), then it appears that
> configure hasn't detected the <termio.h> header.

Hello Glynn,

Hmm, I have two instances of "termios.h", one in /usr/include/termios.h
and /usr/include/sys/termios.h, however I cannot locate a file with the
name "termio.h" anywhere on my system.

<termio.h> is the canonical location for the definition of "struct termio"
(used by the TCGETA/TCSETAW ioctl()s). For GNU libc, this file
contains just:

  #include <termios.h>
  #include <sys/ioctl.h>

The actual "struct termio" definition is in <bits/ioctl-types.h> (this
is highly GNU specific), which is included from <sys/ioctl.h>

> However, the ioctl()s themselves have been superseded by the POSIX.1
> tcgetattr() and tcsetattr() functions.
>
> A more significant "however" is that d.colors/tty.c is redundant; the
> only functions which are used are Get_old_tty() and Get_new_tty().
> These store the terminal settings before and after curses
> initialisation. But the stored settings are never used, i.e. neither
> Old_tty() nor New_tty() are called.
>
> I will commit a fix which removes this code, which should eliminate
> any portability considerations altogether. If you know of any other
> programs which do this, let me know.

I greatly appreciate the information, and better yet a fix!

The fix has been committed to d.colors.

The following 3 modules in addition to d.colors fails for the same
reason:

   i.points
   i.points3
   i.vpoints

i.points/tty.c, i.points3/inter/text_tty.c and i.vpoints/tty.c are all
virtually identical to d.colors/tty.c.

However, 2 of the 3 programs do actually use the functions. Each of
the 3 programs has Suspend_curses() and Resume_curses() functions.

i.points uses these functions in digit.c, surrounding calls to
system($GISBASE/etc/geo.reg) and system($GISBASE/etc/geo.point) in
setup() and digitizer_point().

i.vpoints again uses them in the identically-named digit.c,
surrounding identical calls to system() in, you guessed it, setup()
and digitizer_point().

i.points3 also has a digit.c file, containing setup() and
digitizer_point() functions, featuring rather familiar-looking calls
to system(). However, these *aren't* surrounded by calls to
{Suspend,Resume}_curses(); those functions are not actually used by
i.points3. In fact, text_curses.c isn't even compiled.

Could anyone who is familiar with these programs save me the
trouble of analysing lots of "diff" output and give me an idea of just
how much redundancy is present?

IOW, can they reasonably be merged into a single program, or should
the common code be moved into a library?

For now, I've replaced Old_tty() with endwin() (which is what the
ncurses manpage recommends when exiting curses "mode"), and removed
the calls to Old_tty() (refresh() should re-initialise curses) and
Get_{old,new}_tty() (which aren't required if you don't use
{Old,New}_tty()).

I've commited these changes. Can people check that these programs
still spawn $GISBASE/etc/geo.* correctly on their systems.

--
Glynn Clements <glynn.clements@virgin.net>

5

Jeshua Lacock wrote:

> I will commit a fix which removes this code, which should eliminate
> any portability considerations altogether. If you know of any other
> programs which do this, let me know.

I neglected to mention in my last post that two additional modules,
i.class and i.ortho.photo, fails with the gtty & stty errors as well.

Why am I not remotely surprised to find that i.class and
i.ortho.photo/photo.2image and i.ortho.photo/photo.2target all have
their own copies of the all-too-familiar files tty.c and curses.c?

A quick run of "find ... -name tty.c" also reveals copies in g.help
(with the actual code commented out; all four functions are stubs) and
src/libes/vect32/georef (although this one is basically the "d.colors"
variant, with a few changes of its own).

And that doesn't account for any more "renamed" copies, as with
text_tty.c in i.points3.

So, how many copies have we found so far? Lets see:

  d.colors
  i.points
  i.vpoints
  i.points3
  i.ortho.photo/photo.2image
  i.ortho.photo/photo.2target
  g.help
  src/libes/vect32/georef

And I used to think that src/display/devices had a lot of redundancy.

I'll get around to fixing the rest when I'm in the right frame of mind
(I'm currently alternating between finding it more than a little
amusing and wanting to hunt down those responsible for it).

--
Glynn Clements <glynn.clements@virgin.net>

6

Glynn Clements wrote:

> > I will commit a fix which removes this code, which should eliminate
> > any portability considerations altogether. If you know of any other
> > programs which do this, let me know.
>
> I neglected to mention in my last post that two additional modules,
> i.class and i.ortho.photo, fails with the gtty & stty errors as well.

Why am I not remotely surprised to find that i.class and
i.ortho.photo/photo.2image and i.ortho.photo/photo.2target all have
their own copies of the all-too-familiar files tty.c and curses.c?

A quick run of "find ... -name tty.c" also reveals copies in g.help
(with the actual code commented out; all four functions are stubs) and
src/libes/vect32/georef (although this one is basically the "d.colors"
variant, with a few changes of its own).

OK; I've removed the remaining five occurrences; that seems to be all
of them (although there could still be some lurking within code which
has been removed from the release branch).

I haven't looked into merging the various versions of curses.c yet.
For that, I would be interested in comments as to whether the code
belongs in any of the existing libraries, or if there should be a new
library for curses support routines.

--
Glynn Clements <glynn.clements@virgin.net>

7

On Wed, Jun 06, 2001 at 05:07:30AM +0100, Glynn Clements wrote:

I haven't looked into merging the various versions of curses.c yet.
For that, I would be interested in comments as to whether the code
belongs in any of the existing libraries, or if there should be a new
library for curses support routines.

Glynn, if my guess at the history is correct, maybe these curses files
predate the Vask library? Vask is supposed to be a wrapper for the
variants of curses libraries. So presumably if there's some missing
functionality, it should be ported to the Vask library. Personally, I'm
not sure I like the Vask library too much, seems we could track down a
nicer text/console library.

--
Eric G. Miller <egm2@jps.net>

8

Eric G. Miller wrote:

> I haven't looked into merging the various versions of curses.c yet.
> For that, I would be interested in comments as to whether the code
> belongs in any of the existing libraries, or if there should be a new
> library for curses support routines.

Glynn, if my guess at the history is correct, maybe these curses files
predate the Vask library? Vask is supposed to be a wrapper for the
variants of curses libraries. So presumably if there's some missing
functionality, it should be ported to the Vask library. Personally, I'm
not sure I like the Vask library too much, seems we could track down a
nicer text/console library.

AFAICT, Vask is specifically for inputting data using "forms", rather
than generic curses I/O. It's probably best if it stays this way.

I can see a potential advantage in the Vask interface, namely that it
would be possible to implement a compatible alternative which used GUI
dialogs. An application could then use whichever version was
appropriate, e.g. based upon the GRASS_GUI setting.

It would be nice to updating the API to use more specific types than
just string, integer, long, float and double, though. Similarly for
G_parser(). A further improvement would be to pass "context"
information to enable transparent support for features such as history
lists.

Also, it might be a good idea for G_parser() to use Vask instead of a
teletype-style Q&A session. Either that, or have the program output a
machine-readable argument summary which could be parsed by a generic
front-end or tcltkgrass (which would eliminate the need for all of the
src/tcltkgrass/module/* files).

However, this doesn't answer the question of what to do with programs
for which Vask isn't suitable (e.g. d.colors). The more individual
programs implement their own UI, the harder it is to get consistency
throughout GRASS.

Personally, I'm a firm supporter of separating content from form. In
the context of GRASS, this equates to separating functionality from
interface. Particularly when you have a lot of useful functionality
but the interface often sucks.

BTW, this doesn't really apply to d.colors, which is almost entirely
interface.

Anyway, I'll stop there. The whole "framework" issue is a big can of
worms which is probably best left for 5.1/6.0. For now, I'm just
interested in avoiding duplication where possible.

--
Glynn Clements <glynn.clements@virgin.net>

9

On Wed, Jun 06, 2001 at 06:34:07AM +0100, Glynn Clements wrote:

AFAICT, Vask is specifically for inputting data using "forms", rather
than generic curses I/O. It's probably best if it stays this way.

I can see a potential advantage in the Vask interface, namely that it
would be possible to implement a compatible alternative which used GUI
dialogs. An application could then use whichever version was
appropriate, e.g. based upon the GRASS_GUI setting.

It would be nice to updating the API to use more specific types than
just string, integer, long, float and double, though. Similarly for
G_parser(). A further improvement would be to pass "context"
information to enable transparent support for features such as history
lists.

Also, it might be a good idea for G_parser() to use Vask instead of a
teletype-style Q&A session. Either that, or have the program output a
machine-readable argument summary which could be parsed by a generic
front-end or tcltkgrass (which would eliminate the need for all of the
src/tcltkgrass/module/* files).

See Jan's addition to the parser for and XML interface description.

GRASS ~> <cmd> --interface-description

The dtd is not copied to "etc" though it should be (or share/xml ??).
I was just playing with this the other day to parse the output from
hitting each command with the "--interface-description" flag.
Unfortunately, some modules (and shell scripts), do things before
calling G_parser() that muck this up. An example of parsing this output
to generate an input form exists in grass/src/gui/. I don't
particularly want to add Python and wxWindows as additional requirements
for GRASS, but it shows the possibilities.

However, this doesn't answer the question of what to do with programs
for which Vask isn't suitable (e.g. d.colors). The more individual
programs implement their own UI, the harder it is to get consistency
throughout GRASS.

Personally, I'm a firm supporter of separating content from form. In
the context of GRASS, this equates to separating functionality from
interface. Particularly when you have a lot of useful functionality
but the interface often sucks.

I don't have much experience in the interface arena, but a non-toolkit
specific wrapper that's retargetable for various platforms and i/o
capabilities would be nice. I also would like to merge more
functionality into shared libraries and possibly even most of what
several modules do. A callable command line program would be little
more than processing arguments through G_parser() and calling the
appropriate entry function in a shared lib. Seems to me, this would
make it easier for GUI interfaces to implement the same functionality
without doing system(foo) -- yuck! But then the spec. for the "module"
would need to be handled differently (individual "spec" files?).

BTW, this doesn't really apply to d.colors, which is almost entirely
interface.

Probably d.colors will disappear eventually. 24bit displays are pretty
common...

Anyway, I'll stop there. The whole "framework" issue is a big can of
worms which is probably best left for 5.1/6.0. For now, I'm just
interested in avoiding duplication where possible.

Yea, the changes are stacking up for 5.1/6.0. We need to get 5.0 out so
everyone can move forward. Seems there's an unending supply of triage
work for 5.0 though ;(.

--
Eric G. Miller <egm2@jps.net>

10

Eric G. Miller wrote:

> Also, it might be a good idea for G_parser() to use Vask instead of a
> teletype-style Q&A session. Either that, or have the program output a
> machine-readable argument summary which could be parsed by a generic
> front-end or tcltkgrass (which would eliminate the need for all of the
> src/tcltkgrass/module/* files).

See Jan's addition to the parser for and XML interface description.

GRASS ~> <cmd> --interface-description

OK; so it's already there. In which case, ignore the comments about
using Vask. It seems that the way to go would be to scrap the Q&A and
extend front.end.

The dtd is not copied to "etc" though it should be (or share/xml ??).
I was just playing with this the other day to parse the output from
hitting each command with the "--interface-description" flag.
Unfortunately, some modules (and shell scripts), do things before
calling G_parser() that muck this up.

Do you have any specific cases? That sort of thing should probably be
fixed for 5.0.0.

> However, this doesn't answer the question of what to do with programs
> for which Vask isn't suitable (e.g. d.colors). The more individual
> programs implement their own UI, the harder it is to get consistency
> throughout GRASS.
>
> Personally, I'm a firm supporter of separating content from form. In
> the context of GRASS, this equates to separating functionality from
> interface. Particularly when you have a lot of useful functionality
> but the interface often sucks.

I don't have much experience in the interface arena, but a non-toolkit
specific wrapper that's retargetable for various platforms and i/o
capabilities would be nice. I also would like to merge more
functionality into shared libraries and possibly even most of what
several modules do. A callable command line program would be little
more than processing arguments through G_parser() and calling the
appropriate entry function in a shared lib. Seems to me, this would
make it easier for GUI interfaces to implement the same functionality
without doing system(foo) -- yuck!

Unfortunately it's not that simple.

Right now, a lot of code assumes that it is part of a stand-alone
program, e.g. calling exit() on errors, not keeping track of
dynamically-allocated memory (as it's going to be cleaned up on exit)
and so on.

Personally I don't see any problem with the commands being distinct
programs run as separate processes. The insulation provided by the
Unix process mechanism has its advantages.

As long as the individual commands are implemented with modularity in
mind, it should still be possible to build a decent GUI framework on
top of them. The end result may also have some advantages over a
monolithic application.

The real obstacle is programs which try to be applications in
themselves, e.g. implementing half-baked user-interaction using curses
or (worse still) XDRIVER (e.g. "d.display"). I'm guessing that at
least some of this goes back to pre-X days (I've noticed the reference
to "Tektronix 4105" lurking in the default etc/monitorcap).

But then the spec. for the "module" would need to be handled
differently (individual "spec" files?).

I didn't get this bit.

> BTW, this doesn't really apply to d.colors, which is almost entirely
> interface.

Probably d.colors will disappear eventually. 24bit displays are pretty
common...

That doesn't really relate to the issue of assigning colours to raster
maps. A raster cell stores either a discrete category or scalar value,
not a colour. Regardless of display hardware, colour tables
("palettes") are still an essential part of the process, so a means to
edit them is still necessary.

It seems more likely that d.colors would simply be replaced with a GUI
version. It doesn't seem likely that anyone would want to
interactively edit colour tables without being able to see the results
(which implies running XDRIVER, which implies being able to run a GUI
tool).

--
Glynn Clements <glynn.clements@virgin.net>

11

On Wed, Jun 06, 2001 at 09:00:18AM +0100, Glynn Clements wrote:

Eric G. Miller wrote:
> The dtd is not copied to "etc" though it should be (or share/xml ??).
> I was just playing with this the other day to parse the output from
> hitting each command with the "--interface-description" flag.
> Unfortunately, some modules (and shell scripts), do things before
> calling G_parser() that muck this up.

Do you have any specific cases? That sort of thing should probably be
fixed for 5.0.0.

You asked for it (note, I don't have any of src.garden compiled...)

d.colors
d.colortable
d.db
d.display
d.geodesic
d.icons
d.label
d.labels
d.legend
d.leg.thin
d.measure
d.menu
d.pan
d.points
d.rast.edit
d.save
d.scale
d.sites
d.sites.qual
d.text
d.title
d.what.rast
d.what.sites
d.what.vect
d.zoom
g.access
g.help
g.setproj
g.version
i.class
i.colors
i.composite
i.group
i.ortho.photo
i.points
i.points3
i.quantize
i.rectify
i.tape.mss
i.tape.other
i.tape.spot
i.tape.tm
i.target
i.vpoints
m.examine.tape
m.futil
m.in.stf1.tape
m.lulc.USGS
m.proj
p.chart
p.colors
p.icons
p.labels
r.agnps50.run
r.agnps50.view
r.digit
r.mapcalc
r.mask
r.reclass.scs
r.water.fea
r.weight
tcltkgrass
v.digit
v.export
v.import
v.in.tig.basic
v.in.tig.lndmk
v.out.mapinfo
v.out.moss
v.patch.scs
v.sdts.meta

--
Eric G. Miller <egm2@jps.net>

12

Eric G. Miller wrote:

> > The dtd is not copied to "etc" though it should be (or share/xml ??).
> > I was just playing with this the other day to parse the output from
> > hitting each command with the "--interface-description" flag.
> > Unfortunately, some modules (and shell scripts), do things before
> > calling G_parser() that muck this up.
>
> Do you have any specific cases? That sort of thing should probably be
> fixed for 5.0.0.

You asked for it (note, I don't have any of src.garden compiled...)

These programs fall into five basic categories:

1. False positives (apparently). Most of the listed d.* programs seem
to handle the --interface-description flag fine.

  d.colortable
  d.db
  d.geodesic
  d.icons
  d.label
  d.legend
  d.leg.thin
  d.measure
  d.menu
  d.points
  d.scale
  d.sites
  d.sites.qual
  d.text
  d.title

2. A number of d.* programs obtain defaults for certain options from
the monitor:

  d.colors - D_get_cell_name
  d.pan - D_get_cell_list, D_get_dig_list, D_get_site_list
  d.save - R_screen_{top,bot,left,rite}, R_pad_list, R_pad_select
  d.what.rast - D_get_cell_list
  d.what.sites - D_get_site_list
  d.what.vect - D_get_dig_list
  d.zoom - D_get_cell_list, D_get_dig_list, D_get_site_list

There are two main options for fixing these:

a) Disable the determination of defaults. This is simpler, but removes
potentially useful functionality.

b) Initialise the defaults to a "magic" string, e.g. "<default>" (or
"<default_cell>") etc, then determine the actual values after calling
G_parser.

3. A few programs could use G_parser but don't.

  g.version
  m.in.stf1.tape
  p.chart
  p.labels
  r.agnps50.run
  r.agnps50.view
  v.in.tig.lndmk

4. Most of the remaining programs are strictly interactive. These
basically just won't play nice with any kind of global framework. The
only fix is to extract any useful functionality and incorporate it
into either:

a) one or more command-line utilities (where the program's interactive
nature is gratuitous), or

b) a properly-designed application (where the user interaction is
necessary).

  d.display
  d.labels
  d.rast.edit
  g.access
  g.help
  g.setproj
  i.class
  i.colors
  i.composite
  i.group
  i.ortho.photo
  i.points
  i.points3
  i.quantize
  i.rectify
  i.tape.mss
  i.tape.other
  i.tape.spot
  i.tape.tm
  i.target
  i.vpoints
  m.examine.tape
  m.futil
  m.lulc.USGS
  m.proj
  p.colors
  p.icons
  r.digit
  r.mask
  r.reclass.scs
  r.water.fea
  r.weight
  tcltkgrass
  v.digit
  v.export
  v.import
  v.out.mapinfo
  v.out.moss
  v.patch.scs
  v.sdts.meta

NB: some of these are simply interactive front-ends to command-line
programs (e.g. r.reclass.scs and v.patch.scs).

5. Miscellaneous cases.

  v.in.tig.basic
  r.mapcalc

v.in.tig.basic is almost in the OK category. It calls G_projection to
check that the projection is LL or UTM; this could be done after
G_parser is called.

r.mapcalc could be made to use G_parser (e.g. "expr=..."). Whether to
do so comes down to whether the advantage of consistency outweighs the
disadvantage of changing its syntax.

There's something of a chicken-and-egg situation here. The consistency
doesn't provide any benefit if nothing takes advantage of it, but the
usefulness of a generic front end is reduced if important programs
won't work with it.

Summary: Programs in category 1 don't need changing. I'll look into
fixing those in categories 2 and 3, using option b) for category 2.

Most of category 4 is going to have to stay as-is for 5.0.0, although
some of them might be amenable to "rehabilitation" as command-line
programs without too much work.

--
Glynn Clements <glynn.clements@virgin.net>

13

On Thu, Jun 07, 2001 at 09:01:49AM +0100, Glynn Clements wrote:

These programs fall into five basic categories:

1. False positives (apparently). Most of the listed d.* programs seem
to handle the --interface-description flag fine.

  d.colortable
  d.db
  d.geodesic
  d.icons
  d.label
  d.legend
  d.leg.thin
  d.measure
  d.menu
  d.points
  d.scale
  d.sites
  d.sites.qual
  d.text
  d.title

NOTE: Each one of these produces a Segmentation fault after outputting
the description on the command line. Since I generated the list from a
little script, presumably the segmentation fault was generated before
the interface description had been output to stderr. Possibly still
a problem if another program tries to popen() these programs...

2. A number of d.* programs obtain defaults for certain options from
the monitor:

  d.colors - D_get_cell_name
  d.pan - D_get_cell_list, D_get_dig_list, D_get_site_list
  d.save - R_screen_{top,bot,left,rite}, R_pad_list, R_pad_select
  d.what.rast - D_get_cell_list
  d.what.sites - D_get_site_list
  d.what.vect - D_get_dig_list
  d.zoom - D_get_cell_list, D_get_dig_list, D_get_site_list

There are two main options for fixing these:

a) Disable the determination of defaults. This is simpler, but removes
potentially useful functionality.

b) Initialise the defaults to a "magic" string, e.g. "<default>" (or
"<default_cell>") etc, then determine the actual values after calling
G_parser.

Yea, this is a tough nut, since G_parser might go interactive before the
real defaults could be generated. This was part of the thing I was
trying to get across with the idea of a "spec", or more appropriately
"interface" file. That is, main() could be generated from the interface
file, and other programs could utilize this "interface" file to generate
gui dialogs and such. That'd be a big change though...

3. A few programs could use G_parser but don't.

  g.version
  m.in.stf1.tape
  p.chart
  p.labels
  r.agnps50.run
  r.agnps50.view
  v.in.tig.lndmk

4. Most of the remaining programs are strictly interactive. These
basically just won't play nice with any kind of global framework. The
only fix is to extract any useful functionality and incorporate it
into either:

a) one or more command-line utilities (where the program's interactive
nature is gratuitous), or

b) a properly-designed application (where the user interaction is
necessary).

  d.display
  d.labels
  d.rast.edit
  g.access
  g.help
  g.setproj
  i.class
  i.colors
  i.composite
  i.group
  i.ortho.photo
  i.points
  i.points3
  i.quantize
  i.rectify
  i.tape.mss
  i.tape.other
  i.tape.spot
  i.tape.tm
  i.target
  i.vpoints
  m.examine.tape
  m.futil
  m.lulc.USGS
  m.proj
  p.colors
  p.icons
  r.digit
  r.mask
  r.reclass.scs
  r.water.fea
  r.weight
  tcltkgrass
  v.digit
  v.export
  v.import
  v.out.mapinfo
  v.out.moss
  v.patch.scs
  v.sdts.meta

NB: some of these are simply interactive front-ends to command-line
programs (e.g. r.reclass.scs and v.patch.scs).

5. Miscellaneous cases.

  v.in.tig.basic
  r.mapcalc

v.in.tig.basic is almost in the OK category. It calls G_projection to
check that the projection is LL or UTM; this could be done after
G_parser is called.

r.mapcalc could be made to use G_parser (e.g. "expr=..."). Whether to
do so comes down to whether the advantage of consistency outweighs the
disadvantage of changing its syntax.

There's something of a chicken-and-egg situation here. The consistency
doesn't provide any benefit if nothing takes advantage of it, but the
usefulness of a generic front end is reduced if important programs
won't work with it.

Summary: Programs in category 1 don't need changing. I'll look into
fixing those in categories 2 and 3, using option b) for category 2.

Maybe we could track down the reason for the Segmentation fault's in
category 1, as the interface description output seems to fail when
called from a script.

Most of category 4 is going to have to stay as-is for 5.0.0, although
some of them might be amenable to "rehabilitation" as command-line
programs without too much work.

I guess a program that would use this mechanism could blacklist
"category 4" programs...

--
Eric G. Miller <egm2@jps.net>

14

Eric G. Miller wrote:

> These programs fall into five basic categories:
>
> 1. False positives (apparently). Most of the listed d.* programs seem
> to handle the --interface-description flag fine.

[snip]

NOTE: Each one of these produces a Segmentation fault after outputting
the description on the command line.

Not here, they don't.

Maybe we could track down the reason for the Segmentation fault's in
category 1, as the interface description output seems to fail when
called from a script.

I don't see it, so I'll need you to track it down.

> Most of category 4 is going to have to stay as-is for 5.0.0, although
> some of them might be amenable to "rehabilitation" as command-line
> programs without too much work.

I guess a program that would use this mechanism could blacklist
"category 4" programs...

It might be nice if --interface-description still worked, e.g.
outputting a description which stated that the program was
interactive-only.

There's also the question of whether any of these programs provide
useful functionality which isn't available in any existing
command-line program.

--
Glynn Clements <glynn.clements@virgin.net>

15

On Thu, Jun 07, 2001 at 05:03:42PM +0100, Glynn Clements wrote:

Eric G. Miller wrote:

> > These programs fall into five basic categories:
> >
> > 1. False positives (apparently). Most of the listed d.* programs seem
> > to handle the --interface-description flag fine.

[snip]

> NOTE: Each one of these produces a Segmentation fault after outputting
> the description on the command line.

Not here, they don't.

Do you have a graphics device running? Most of the ones I've looked at
have a call to R_open_driver(), or don't call G_gisinit() before
defining module options (bad).

> > Most of category 4 is going to have to stay as-is for 5.0.0, although
> > some of them might be amenable to "rehabilitation" as command-line
> > programs without too much work.
>
> I guess a program that would use this mechanism could blacklist
> "category 4" programs...

It might be nice if --interface-description still worked, e.g.
outputting a description which stated that the program was
interactive-only.

Depending on the module, this shouldn't be too hard. But, the module
must have a version in grass5/etc/bin/cmd/ otherwise the front end
intercepts the command line call with parameters (all that gmakelink5
line noise stuff). There's nothing in the grass-interface.dtd to flag
an interactive or console-interactive module. Perhaps such an addition
would be useful? I just did such a thing with d.display, but I won't
commit it for the time being since the XML output isn't very useful (the
description from the "man" page).

There's also the question of whether any of these programs provide
useful functionality which isn't available in any existing
command-line program.

Somebody must've thought so at one time :wink:

--
Eric G. Miller <egm2@jps.net>

16

Eric G. Miller wrote:

> > > These programs fall into five basic categories:
> > >
> > > 1. False positives (apparently). Most of the listed d.* programs seem
> > > to handle the --interface-description flag fine.
>
> [snip]
>
> > NOTE: Each one of these produces a Segmentation fault after outputting
> > the description on the command line.
>
> Not here, they don't.

Do you have a graphics device running?

No. I wouldn't have found the category 2 cases if I had.

Most of the ones I've looked at have a call to R_open_driver(),

That applies to all of the category 2 cases.

or don't call G_gisinit() before defining module options (bad).

OK; some of them do call G_define_module before G_gisinit(). However,
I can't see why that would actually cause problems; AFAICT, neither
G_define_module nor G_define_option rely upon anything having been
initialised.

Having said that, if G_gisinit(argv[0]) is meant to be called before
anything else, I'll make changes where necessary.

> > > Most of category 4 is going to have to stay as-is for 5.0.0, although
> > > some of them might be amenable to "rehabilitation" as command-line
> > > programs without too much work.
> >
> > I guess a program that would use this mechanism could blacklist
> > "category 4" programs...
>
> It might be nice if --interface-description still worked, e.g.
> outputting a description which stated that the program was
> interactive-only.

Depending on the module, this shouldn't be too hard. But, the module
must have a version in grass5/etc/bin/cmd/ otherwise the front end
intercepts the command line call with parameters (all that gmakelink5
line noise stuff).

Maybe front.end could trap the case where --interface-description is
used.

There's nothing in the grass-interface.dtd to flag
an interactive or console-interactive module. Perhaps such an addition
would be useful?

I think so.

I'm not sure if we need to have a function to declare interactive-only
behaviour. It may suffice to test "!n_flags && !n_opts".

--
Glynn Clements <glynn.clements@virgin.net>

17

On Fri, Jun 08, 2001 at 06:11:04AM +0100, Glynn Clements wrote:

OK; some of them do call G_define_module before G_gisinit(). However,
I can't see why that would actually cause problems; AFAICT, neither
G_define_module nor G_define_option rely upon anything having been
initialised.

Turns out bug was in G_usage_xml() in libes/gis/parser.c:

It had something like:
  s = (char *) calloc (strlen(opt->options), 1);
  strcpy (s, opt->options);

Eventually, not having that '\0' terminator causes a problem.

Having said that, if G_gisinit(argv[0]) is meant to be called before
anything else, I'll make changes where necessary.

That's what's recommended in the programming manual. Set's up the
environment and such, and just maybe a function call might depend on
something being set up.

> Depending on the module, this shouldn't be too hard. But, the module
> must have a version in grass5/etc/bin/cmd/ otherwise the front end
> intercepts the command line call with parameters (all that gmakelink5
> line noise stuff).

Maybe front.end could trap the case where --interface-description is
used.

Well, we could probably do that in the short term. Longer term'ish was
to get rid of the distinction between the "command" and "inter" programs
and therefore just put all the binaries in grass5/bin (or maybe better
grass5/libexec). There are several programs that can't really have a
non-interactive version, but we should at least let G_parser() have the
first crack at the command.

> There's nothing in the grass-interface.dtd to flag
> an interactive or console-interactive module. Perhaps such an addition
> would be useful?

I think so.

I'm not sure if we need to have a function to declare interactive-only
behaviour. It may suffice to test "!n_flags && !n_opts".

That'd be a decent heuristic. Off the top of my head I can't think of a
module that doesn't take arguments and isn't required to be
interactive. Though, I suppose it could be possible.

--
Eric G. Miller <egm2@jps.net>