I think I've fixed v.digit for Solaris

[David Houlder]

Folks...

I think I've fixed the problem that prevents v.digit from working under
Solaris 2.x.  The digitizer I/O was inadvertantly put into a state
where an attempt to read characters when none were available would
return a zero byte count, rather than waiting for a character to
arrive. v.digit interprets the 0 byte count as an error. A diff on the
old and new files (graph_input.c) shows the fix: The lines starting
with '+' are the fix.

zygochloa% diff -c /opt/source/grass/s4/src/mapdev/v.digit/graph_input.c graph_input.c
*** /opt/source/grass/s4/src/mapdev/v.digit/graph_input.c       Wed May 17 17:54:37 1995
--- graph_input.c       Wed Nov  1 10:57:25 1995
***************
*** 598,603 ****
--- 598,615 ----
          termvar.c_cc[VEOF] = 0 ;
          termvar.c_cc[VEOL] = 0 ;
          termvar.c_lflag = 0 ;
+ 
+       /* Fix for Solaris 2.x (David Houlder, ANU, November 1995)
+        * VMIN and VTIME are the same elements as VEOF and VEOL,
+        * which have been set to 0 above. With VMIN==0,VTIME==0
+        * read() never blocks, returning 0 when no chars are
+        * available, which v.digit interprets as an I/O error.
+        * VMIN==1 makes the read wait for at least 1 char
+        */
+         termvar.c_cc[VMIN] = 1 ;
+         termvar.c_cc[VTIME] = 0 ;
+ 
+ 
      }
          /*** set parity    ***/
      switch(digdevice.parity) {




Anybody care to investigate this VMIN,VTIME/VEOL,VEOF problem on
another sysv unix? It might just be a Solaris quirk. I've only tested
it with one digitizer (Kurta XGT pretending to be Summa UIOF) in ascii
mode, but the fix should work for binary mode too.


David Houlder			        Phone:	+61 6 249 4613
Geography Department	       	    (In Aust.:	(06) 249 4613)
The Australian National University	  Fax:	+61 6 249 3770
--------------------------------------------------------------