[GRASS5] Re: "spawn"

[Glynn Clements]

Jeshua Lacock wrote:

> > 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.
> 
> Thanks for the fix.  After updating, d.colors has now been compiled for 
> Darwin.
> 
> Could you please explain what you mean by "spawn"?  And I will test it 
> here.  I assume you mean execute?

Basically, yes. More precisely, "execute as a child process" as in
system() rather than "execute in place of the current program" as in
the various exec*() functions.

Note that this doesn't apply to d.colors, which wasn't actually using
the tty functions anyway. It's only relevant to the i.*points*
commands.

Actually, I don't know if you will be able to test it; I don't have
$GISBASE/etc/geo.{reg,point} here, which are the commands which are
supposed to be spawned.

I've just looked into this, and noticed the following in
src/libes/vect32/georef/Gmakefile:

	#  notice that bin_reg becomes geo.reg in the etc directory
	
	$(ETC)/geo.reg: bin_reg.o $(GISLIB) $(LOCKLIB)
		$(CC) $(LDFLAGS)  -o $(ETC)/bin_reg  bin_reg.o  libgeo.a  $(GISLIB) $(LOCKLIB) $(MATHLIB) $(XDRLIB) 
	
	
	#  notice that bin_point becomes geo.point in the etc directory
	
	$(ETC)/geo.point: bin_point.o $(GISLIB) $(LOCKLIB)
		$(CC) $(LDFLAGS)  -o $(ETC)/bin_point  bin_point.o  libgeo.a $(GISLIB) $(LOCKLIB) $(MATHLIB) $(XDRLIB)

I do have $GISBASE/etc/bin_{reg,point}; but those aren't the names
which i.*points* are using. Given that system() is running commands
which don't actually exist, whether or not the terminal is set up
correctly is largely irrelevant ;)

NB: "cvs log Gmakefile" indicates that it's been this way since it was
imported into CVS on 1999/12/29.

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