[GRASS5] Darwin Pre1 gtty stty errors

[Glynn Clements]

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 at virgin.net>