[comp.unix.programmer] winsize struct

pjh@mccc.edu (Pete Holsberg) (02/12/91)

A couple of the programs I've tried to compile have required the winsize
struct, found in <ptem.h>, I believe.  However, with both Microport's
K&R compiler and with the AT&T ANSI compiler, there is *no* include file
that defines that struct!

If someone could send me the definition, I'd be grateful.

Thanks,
Pete
-- 
Prof. Peter J. Holsberg      Mercer County Community College
Voice: 609-586-4800          Engineering Technology, Computers and Math
UUCP:...!princeton!mccc!pjh  1200 Old Trenton Road, Trenton, NJ 08690
Internet: pjh@mccc.edu	     Trenton Computer Festival -- 4/20-21/91

jik@athena.mit.edu (Jonathan I. Kamens) (02/13/91)

In article <1991Feb11.192013.6587@mccc.edu>, pjh@mccc.edu (Pete Holsberg) writes:
|> A couple of the programs I've tried to compile have required the winsize
|> struct, found in <ptem.h>, I believe.  However, with both Microport's
|> K&R compiler and with the AT&T ANSI compiler, there is *no* include file
|> that defines that struct!
|> 
|> If someone could send me the definition, I'd be grateful.

  First of all, on many systems, the winsize structure is defined in
<sys/ioctl.h>, not in <ptem.h>.

  Second, if you're using a system that doesn't define the winsize structure
in any of its header files, the most likely explanation is that the system
doesn't *support* the SIGWINCH signal or the TIOCGWINSZ and TIOCSWINSZ
ioctl's, so defining the structure isn't going to help you.

  The programs should be written in such a way that allows you to disable the
use of the winsize stuff.  If they aren't, they should be modified so that
they are, using preprocessor symbols to determine whether the system on which
they are being compiled has winsize.

-- 
Jonathan Kamens			              USnail:
MIT Project Athena				11 Ashford Terrace
jik@Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8085			      Home: 617-782-0710

scs@adam.mit.edu (Steve Summit) (02/13/91)

In article <1991Feb12.211450.28938@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes:
>...if you're using a system that doesn't define the winsize structure
>in any of its header files, the most likely explanation is that the system
>doesn't *support* the SIGWINCH signal or the TIOCGWINSZ/TIOCSWINSZ ioctl's...
>The programs should be written in such a way... to disable the... winsize
>stuff... using preprocessor symbols to determine whether the system on which
>they are being compiled has winsize.

Furthermore, this is one happy case in which you *don't* have to
invent your own preprocessor symbols.  (Jon probably understands
this, but I want to make the notion explicit.)  The code in
question can be made conditional on

	#ifdef SIGWINCH

and/or

	#ifdef TIOCSWINSZ

No Makefile editing, no config scripts, no multiplicity-of-
features-lumped-under-one-OS-specific-macro.  (Of course,
figuring out what to #include may be tricky, but here it really
ought to be <signal.h> and <sgtty.h>, respectively.)

With a bit of creativity, you can use tricks like these for a
number of other OS-dependent features.  For example, make your
symbolic link support conditional on S_IFLNK, after #including
<sys/stat.h>.  (If you try to make symbolic link code conditional
on something like BSD4, you make life difficult for people trying
to compile the code on a non-BSD system which does have symbolic
links but which otherwise isn't much like BSD.)  Don't put the
code for catching SIGTSTP inside #ifdef JOBCONTROL; put it inside
#ifdef SIGTSTP.  Settable line disciplines?  TIOCSETD.
Etc.

                                            Steve Summit
                                            scs@adam.mit.edu

chip@tct.uucp (Chip Salzenberg) (02/13/91)

According to scs@adam.mit.edu:
>	#ifdef SIGWINCH
>	#ifdef TIOCSWINSZ

Yup.  Just what the doctor ordered.

>(Of course, figuring out what to #include may be tricky, but here
>it really ought to be <signal.h> and <sgtty.h>, respectively.)

Signal, sure.  But you can't include <sgtty.h> on SCO UNIX, even
though it has TIOCSWINSZ.  Try:

     #if defined(POSIX)
     #include <termios.h>
     #else
     #if defined(USG)
     #include <termio.h>
     #else
     #include <sgtty.h>
     #endif
     #endif

(Macro POSIX and/or USG set from the command line.)

>With a bit of creativity, you can use tricks like these for a
>number of other OS-dependent features.

For future tty mode hacking, I'd like to suggest that all OS-dependent
code be implemented, as much as possible, in terms of POSIX functions
like tcgetattr(), tcsetattr(), tcflush(), etc.
-- 
Chip Salzenberg at Teltronics/TCT     <chip@tct.uucp>, <uunet!pdn!tct!chip>
 "I want to mention that my opinions whether real or not are MY opinions."
             -- the inevitable William "Billy" Steinmetz

brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (02/14/91)

In article <1991Feb13.032238.11640@athena.mit.edu> scs@adam.mit.edu writes:
  [ use #ifdef SIGWINCH for winsize; use #ifdef S_IFLNK for symlinks ]
> Don't put the
> code for catching SIGTSTP inside #ifdef JOBCONTROL; put it inside
> #ifdef SIGTSTP.  Settable line disciplines?  TIOCSETD.
> Etc.

I have to disagree. There may be occasional cases where the macros
provided by the system exactly match the features you want to use, but
you'll never lose anything by sticking to #ifdef JOBCONTROL and putting

	#ifdef SIGTSTP
	#define JOBCONTROL
	#endif

inside a .h file. This way someone can (1) figure out what you really
meant while reading the code; (2) change the definitions with as little
work as possible in case you messed up.

---Dan