From: Digestifier To: Linux-Misc@senator-bedfellow.mit.edu Reply-To: Linux-Misc@senator-bedfellow.mit.edu Date: Sat, 4 Sep 93 22:13:12 EDT Subject: Linux-Misc Digest #95 Linux-Misc Digest #95, Volume #1 Sat, 4 Sep 93 22:13:12 EDT Contents: Man Pages, Libraries (Danek Duvall) Re: bsd vs linux???? (Bill Heiser) Re: Low Cost SLS 1.03 on Diskette (Bill Heiser) Getting TIOCGETP TIOCSETN undeclared. Help. (Craig T Manske) Re: SLS considered harmful (wasRe: Bashing Peter MacDonald) (Matt Welsh) Re: Low Cost SLS 1.03 on Diskette (John Henders) Re: Getting TIOCGETP TIOCSETN undeclared. Help. (Charles T Wilson -- Personal Account) Re: AMD 386 40 problem ? (Alvin P. Phillips) [Q] Anyone tried porting BSD pc (pascal compiler)? (Eugene Kim) Re: Getting TIOCGETP TIOCSETN undeclared. Help. (Todd C. Miller) ---------------------------------------------------------------------------- From: duvalld@liberty.uc.wlu.edu (Danek Duvall) Subject: Man Pages, Libraries Date: Sat, 4 Sep 1993 18:51:26 GMT I have a couple of questions on man pages: 1. Where can I get pages for sections 2 & 3 of the manual that don't come with linux, i.e., printf, etc... I got the slackware release, so I don't know if they came with SLS. Right now, I've got the info files from glibc 1.06, but I don't think that's quite right. Anyway, I want man pages. If these are part of the unfinished LDP, then sorry for asking, but just in case ... 2. Is there any way to get xman to read gzipped pages? 3. Is there any better documentation on man page nroff macros than in man(7)? And a couple of questions about the libraries: 1. Where do the routines in libc.a come from? Especially the drand48() family? They don't exist anywhere I've looked, but there are prototypes floating around. Are they functions I shouldn't use? 2. How do you make sure that a program is compiled to use the shared libraries, rather than the static ones? I'm short on disk space, and haven't used any special flags or anything. 3. How do you create a shared library? I've got a bunch of routines in a library, but would like to make the thing dynamically linkable. Thanks for any answers, Danek -- Danek Duvall: Washington and Lee U. Internet: duvalld@liberty.uc.wlu.edu *** ------------------------------ From: heiser@bumetb.bu.edu (Bill Heiser) Crossposted-To: comp.os.386bsd.misc Subject: Re: bsd vs linux???? Date: 4 Sep 1993 19:51:25 GMT Reply-To: heiser@bumetb.bu.edu (Bill Heiser) In article <2683ju$k15@nic.umass.edu> ranger@twain.ucs.umass.edu (Net Ranger) writes: > >(2) What are some peoples observances about the differences (people who have >tried both please) I tried 386BSD several months ago. After *many* trials and tribulations, I got it to install correctly. But even then, there were several basic *blatant* bugs. Even simple things like 'cd' and 'ls' had bugs severe enough so that I wrote 386BSD off as "unusable in its present state". With LINUX (SLS 1.03), I just installed it, and with just a couple of fix-ups to correct for install problems, it's been pretty much fine since then. There are a few problems I've encountered, but the base OS seems *much* more stable than 386BSD. Just MHO, and your mileage may (probably will) vary :-) ------------------------------ From: heiser@bumetb.bu.edu (Bill Heiser) Subject: Re: Low Cost SLS 1.03 on Diskette Date: 4 Sep 1993 19:55:07 GMT Reply-To: heiser@bumetb.bu.edu (Bill Heiser) In article <268sjc$qjg@clarknet.clark.net> stephen@clarknet.clark.net (Stephen Balbach) writes: >I don't think the problem is distributing disks for a charge. Most will >agree this is a needed service. >The problem is advertising on USENET. And the problem is when 10 >diffrent companies all vie for the readers attention, suddenly c.o.l.* >becomes a junk mail-box, somthing know one wants. I think another solution (besides the "catalog" thing you suggested) would be for the FAQ maintainer to list the prominent sources for LINUX-on-floppies along with pricing and order info. Posting to the c.o.l group could be prohibited, and all such "ads" would ahve to be sent to the FAQ maintainer. ------------------------------ From: albion@csd4.csd.uwm.edu (Craig T Manske) Crossposted-To: comp.os.linux.help,comp.os.linux.development Subject: Getting TIOCGETP TIOCSETN undeclared. Help. Date: 4 Sep 1993 21:02:34 GMT I am trying to port pmf mud client to Linux and am having problems with some undeclared things. These are TIOCGETP, TIOCSETN, CBREAK, ODDP, EVENP. I changed ODDP and EVENP to O_ODDP and O_EVENP. But the others are non existant. I looked on my local BSD machine at school and they are defined in ioctl.h. All the stuff on my Linux box that is in ioctl.h on the BSD machine are in termios.h except for TIOCGETP and TIOCSETN. Is this something not included with Linux? Also, I got the error _cnt not included in structure. I again looked on the BSD machine and this was an int in stdio.h and the somewhat equivalent in Linux was _gptr. So I changed it to that in the file instead of _cnt. Am I doing this right, or am I messing things up? Please help me. I would like to get PMF running on my machine. Thanx in advance. Albion albion@csd4.csd.uwm.edu ------------------------------ From: mdw@sunSITE.unc.edu (Matt Welsh) Subject: Re: SLS considered harmful (wasRe: Bashing Peter MacDonald) Date: 5 Sep 1993 00:00:43 GMT Stephen Harris (harris@teaching.physics.ox.ac.uk) wrote: > I couldn't imagine anything better. THEN SLS created a 30 disk setup! After > a lot of phone calls (no direct connection) I grabbed SLS. 1 week later it > changed. I grabbed the changes. 1 week later it changed again. I got the > changes. 2 days later it changed again! Sounds like a silly upgrade strategy to me. First of all, there's little or no reason to download the ENTIRE SLS package, not at once anyway. Probably a,b,c, and x will do initially. But if you do spend the time to download and install the entire system, there's not a lot of reason to upgrade every single time SLS comes out with a new version. Some people can grab the "fixes" packages and apply them, but they only work for a single "patch level" behind. I know some people who download and reinstall the ENTIRE SLS distribution every time it comes out with a new version. Of course that is ridiculous, but many people don't feel comfortable upgrading my hand: to many people, even recompiling the kernel gives them nightmares. The solution to the problem is not to keep SLS at a single "stable" release for months on end. The solution is only to upgrade incrementally and only when absolutely necessary. I'm still running 0.99.pl10, which is considered the Linux Stone Age. Most of my binaries are left over from an ancient circa 0.95+/0.97 MCC installation. The only time I upgrade is when I feel a *need* to upgrade; I got XFree86 1.3 because it supports my SVGA card. I got 0.99.pl10 to play with "official" NET-2 although I was running alpha NET-2 long before that. Linux is not MS-DOS. Every time a new version comes out you are not expected to upgrade to it. The very least you should do is upgrade your kernel and libraries as needed. But not very much of the software changes in between SLS releases. Put simply, if you upgrade every time a new version of something comes out, you'll spend all of your time upgrading and none of your time using the system. Upgrading is boring, anyway. Sometimes it's fun to run ancient software for months and come back to a new version after a while and see how things have progressed. :) mdw -- Send submissions for comp.os.linux.announce to: linux-announce@tc.cornell.edu ------------------------------ From: jhenders@jonh.wimsey.bc.ca (John Henders) Subject: Re: Low Cost SLS 1.03 on Diskette Date: Sun, 5 Sep 1993 00:34:42 GMT heiser@bumetb.bu.edu (Bill Heiser) writes: >I think another solution (besides the "catalog" thing you suggested) >would be for the FAQ maintainer to list the prominent sources for >LINUX-on-floppies along with pricing and order info. Posting to the >c.o.l group could be prohibited, and all such "ads" would ahve to be >sent to the FAQ maintainer. How about a prohibition on posting the ads to any linux group but annnounce? Then the moderator could make sure the ads in announce all have the same title so those who don't want to see them can efficiently kill them. -- John Henders GO/MU/E d* -p+ c+++ l++ t- m--- s/++ g+ w+++ -x+ ------------------------------ From: ctwilson@rock.concert.net (Charles T Wilson -- Personal Account) Crossposted-To: comp.os.linux.help,comp.os.linux.development Subject: Re: Getting TIOCGETP TIOCSETN undeclared. Help. Date: 5 Sep 1993 01:23:34 GMT In article <26avpaINN40n@uwm.edu> albion@csd4.csd.uwm.edu (Craig T Manske) writes: > >I am trying to port pmf mud client to Linux and am having problems with some >undeclared things. > >These are TIOCGETP, TIOCSETN, CBREAK, ODDP, EVENP. > >I changed ODDP and EVENP to O_ODDP and O_EVENP. >But the others are non existant. I looked on my local BSD machine at >school and they are defined in ioctl.h. All the stuff on my Linux box >that is in ioctl.h on the BSD machine are in termios.h except for >TIOCGETP and TIOCSETN. Is this something not included with Linux? I don't think so...BSD handles its I/O through ioctl.h defs, while the SYSV and POSIX approach is to do this with termios.h defs; and, as you noticed, stdio is quite a bit different too. > >Also, I got the error _cnt not included in structure. I again looked on >the BSD machine and this was an int in stdio.h and the somewhat equivalent >in Linux was _gptr. So I changed it to that in the file instead of _cnt. >Am I doing this right, or am I messing things up? > >Please help me. I would like to get PMF running on my machine. Wish I could...I've dabbled with the conversions but can't ever seem to find the time to get it right. The best thing I know to do is keep making comparisons; you'll find equivalents for some things pretty easily, some not so easily. Good luck! -- /-----------------------------------------------------------------------\ | Tom Wilson | "I can't complain, but sometimes | | ctwilson@rock.concert.net | I still do." | | | -Joe Walsh | ------------------------------ From: phillip@seq.uncwil.edu (Alvin P. Phillips) Subject: Re: AMD 386 40 problem ? Date: Sun, 5 Sep 1993 01:46:43 GMT harris@teaching.physics.ox.ac.uk (Stephen Harris) writes: >Have I got a bad machine, or is there a known problem with the AMD386-40 ? >Linux is convinced I have a co-pro using exception 13 reporting, and so >a lot of maths gets confused. Using LILO with the "no387" flag gets around >the problem, but this is a pain to remember this machine is special when >admining a potential 30 machines over 7 sites. >Any feed back would be welcome. Thanks. I've been running Linux on 2 386-40's for about a year now ( since 0.97.4) I haven't experienced any problems yet, so it's probably not the chip's fault. sorry, Alvin... :-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-) :-) PHILLIPSA@VXC.OCIS.UNCWIL.EDU :-) I swear, I didn't do it... :-) :-) phillip@seq.cms.uncwil.edu :-) Alvin P. Phillips :-) :-)seq.cms.uncwil.edu!poeman!phillip :-) "POEMAN" :-) :-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-) ------------------------------ Subject: [Q] Anyone tried porting BSD pc (pascal compiler)? From: eekim@husc11.harvard.edu (Eugene Kim) Date: 4 Sep 93 21:18:04 EDT Hi, I was browsing the BSD sources in ftp.uu.net today, and I discovered sources for the pc compiler. From what I've followed on the newsgroups and from what I've seen on the Linux ftp sites, no one has ported a pascal compiler to Linux yet. Has someone tried porting the BSD sources for pc to Linux? If so, is there a reason why pc cannot be ported to Linux? If no one has attempted to port pc, and there's no reason not to (ie. legal, impossible), I'll go ahead and try to port it. I just want to make sure it hasn't been tried before. -- . Eugene Eric Kim ......................................................... . eekim@husc.harvard.edu .................................................. . "Dangerous stuff, science. Lots of us not fit for it." .. ........................................ -H.C. Bailey, "The Long Dinner" .. ------------------------------ Crossposted-To: comp.os.linux.help,comp.os.linux.development From: Todd C. Miller Subject: Re: Getting TIOCGETP TIOCSETN undeclared. Help. Reply-To: millert@Colorado.EDU (Todd C. Miller) Date: Sun, 5 Sep 1993 01:57:58 GMT Here is info on bsd tty -> termio conversion(s) that deals with irix but should be applicable to linux as well. cheers, todd Article 14130 of comp.sys.sgi: Newsgroups: comp.sys.sgi Path: boulder!agate!ames!sun-barr!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!jvnc.net!nj.nec.com!cliff From: cliff@research.nj.nec.com (the man who fries burgers while reading sartre at night) Subject: how to use BSD sgttyb on an SGI (long) (was: Re: sgttyb and libg++) Message-ID: <1992May16.171822.7377@research.nj.nec.com> Originator: cliff@research.nj.nec.com Sender: news@research.nj.nec.com Organization: NEC Research Institute Date: Sat, 16 May 92 17:18:22 GMT Lines: 310 In article <1992May9.224026.650@elroy.jpl.nasa.gov>, richard@elroy.jpl.nasa.gov (Richard Weidner) wrote: > I found a reference to struct sgttyb in > but it is not defined in any of the include files in > /usr/include. It is required to compile > libg++. Is there a patch somewhere to put > this in the include files? > > It is defined in as > struct sgttyb { > char sg_ispeed; /* input speed */ > char sg_ospeed; /* output speed */ > char sg_erase; /* erase character */ > char sg_kill; /* kill character */ > short sg_flags; /* mode flags */ > }; > on Sun Computers. > and in , vjs@rhyolite.wpd.sgi.com (Vernon Schryver) replied: > That definition is as useful as any other (i.e. probably useless), since > the IRIX kernel does not support the IOCTL's and (I don't think) anyone has > gotten around to writting code to fake them out of TCGET/SET. well, the below is a beginning, after my (mostly successful) attempt to port talk from the original BSD source to the SGI. it may not explain everything about sgtty and termio, but it gets you on your way if you just want to do a port of something from BSD... ====================================================================== how to do BSD sgttyb stuff on an SGI... cliff miller 5/16/92 cliff@research.nj.nec.com this short article is for people who've tried to port a BSD-flavor app that uses some kind of tty control (curses, etc.) to a SysV platform. typically the port goes fine except for the tty part, which is nigh impossible to figure out without serious digging. this example illustrates the port from Sun 4.0.3 to SGI IRIX 3.3.3, though in principle it should work in other cases, with a few name changes. in BSD (i'm using SunOS 4.0.3 as the working example...) one had the following structs in : ---- begin excerpt of BSD ----------------------------------- /* @(#)ttold.h 1.6 88/02/08 SMI; from S5R2 6.1 */ #ifndef _TTOLD_ #define _TTOLD_ struct tchars { char t_intrc; /* interrupt */ char t_quitc; /* quit */ char t_startc; /* start output */ char t_stopc; /* stop output */ char t_eofc; /* end-of-file */ char t_brkc; /* input delimiter (like nl) */ }; struct ltchars { char t_suspc; /* stop process signal */ char t_dsuspc; /* delayed stop process signal */ char t_rprntc; /* reprint line */ char t_flushc; /* flush output (toggles) */ char t_werasc; /* word erase */ char t_lnextc; /* literal next character */ }; /* * Structure for TIOCGETP and TIOCSETP ioctls. */ #ifndef _SGTTYB_ #define _SGTTYB_ struct sgttyb { char sg_ispeed; /* input speed */ char sg_ospeed; /* output speed */ char sg_erase; /* erase character */ char sg_kill; /* kill character */ short sg_flags; /* mode flags */ }; #endif */ ---- end excerpt ------------------------------------------------------- this would typically appear in code using curses.h, in the tty setup, such as the following. ---- begin [abbreviated] excerpt of BSD talk.c ------------------------- struct ttywin { char kill; char cerase; char werase; } my_win; /* ... */ struct sgttyb tty; struct ltchars ltc; ioctl(0, TIOCGETP, &tty); /* does what gtty(3C) used to do */ ioctl(0, TIOCGLTC, (struct sgttyb *)<c); my_win.cerase = tty.sg_erase; my_win.kill = tty.sg_kill; if (ltc.t_werasc == (char) -1) my_win.werase = '\027'; /* control W */ else my_win.werase = ltc.t_werasc; buf[0] = my_win.cerase; buf[1] = my_win.kill; buf[2] = my_win.werase; ---- end excerpt ------------------------------------------------------- basically the above code goes and finds out some of the 'stty' settings of the invoking terminal. now on an SGI, there is no such thing as , and the above ioctl() calls won't work either. but after some digging one discovers that does the trick instead... (detailed explanation of this in SGI's termio(7)). ---- begin excerpt of ------------------------------------- /* terminal I/O definitions * some System V, some BSD. * * $Revision: 3.22 $ */ #ifndef __TERMIO_H__ #define __TERMIO_H__ #define NCC 8 #define NCC_PAD 7 /* padding in case next version of SV extends NCC */ #define NCC_EXT 16 /* SGI extensions to SVR3 set */ #define NCCS (NCC+NCC_PAD+NCC_EXT) /* control characters */ #define VINTR 0 #define VQUIT 1 #define VERASE 2 #define VKILL 3 #define VEOF 4 #define VEOL 5 #define VEOL2 6 #define VMIN VEOF #define VTIME VEOL #define VSWTCH 7 #define VLNEXT (NCC+NCC_PAD+0) /* take next character literally */ #define VWERASE (NCC+NCC_PAD+1) /* erase previous word (LDISC1) */ #define VRPRNT (NCC+NCC_PAD+2) /* retype the line (LDISC1) */ #define VFLUSHO (NCC+NCC_PAD+3) /* flush output (LDISC1) */ #define VSTOP (NCC+NCC_PAD+4) /* XOFF */ #define VSTART (NCC+NCC_PAD+5) /* XON */ /* ... */ typedef unsigned short tcflag_t; typedef unsigned char cc_t; /* ... */ struct termio { tcflag_t c_iflag; /* input modes */ tcflag_t c_oflag; /* output modes */ tcflag_t c_cflag; /* control modes */ tcflag_t c_lflag; /* line discipline modes */ char c_line; /* line discipline */ cc_t c_cc[NCCS]; /* control chars */ }; ---- end excerpt ------------------------------------------------------- the termio struct is obtained on an SGI with struct termio myterm; ioctl(0,TCGETA,&myterm); /* gets fd 0, i.e. stdin */ the array myterm.c_cc[NCCS] then holds all the control characters that the BSD structs tchars and ltchars did, and can be modified and then reset using the SGI call ioctl(0,TCSETA,&myterm); or others as documented in "System Calls" under termio(7). below is a mapping of the BSD struct elements to the corresponding termio elements: --- begin commented excerpt of BSD ----------------------- struct tchars { char t_intrc; /* termio.c_cc[VINTR] */ char t_quitc; /* termio.c_cc[VQUIT] */ char t_startc; /* termio.c_cc[VSTART] */ char t_stopc; /* termio.c_cc[VSTOP] */ char t_eofc; /* termio.c_cc[VEOF] */ char t_brkc; /* termio.c_cc[VEOL] */ }; struct ltchars { char t_suspc; /* termio.c_cc[VSWTCH] */ char t_dsuspc; /* not implemented yet - see CDSUSP (^Y) */ char t_rprntc; /* termio.c_cc[VRPRNT] */ char t_flushc; /* termio.c_cc[VFLUSHO] */ char t_werasc; /* termio.c_cc[VWERASE] */ char t_lnextc; /* termio.c_cc[VLNEXT] */ }; /* * Structure for TIOCGETP and TIOCSETP ioctls. */ #ifndef _SGTTYB_ #define _SGTTYB_ struct sgttyb { char sg_ispeed,sg_ospeed; /* termio.c_cflag & 017 - see termio(7), "Control Modes" */ char sg_erase; /* termio.c_cc[VERASE] */ char sg_kill; /* termio.c_cc[VKILL] */ short sg_flags; /* termio.c_iflag,c_oflag */ }; --- end excerpt -------------------------------------------------------- the sg_flags map like this (at least this is all i've gotten so far): --- begin excerpt of BSD man page ttcompat(4M) ------------------------- The sg_flags field of the argument structure contains several flags that determine the system's treatment of the terminal. They are mapped into flags in fields of the ter- minal state, represented by the termio structure. Delay type 0 is always mapped into the equivalent delay type 0 in the c_oflag field of the termio structure. Other delay mappings are performed as follows: sg_flags c_oflag BS1 BS1 FF1 VT1 CR1 CR2 CR2 CR3 CR3 not supported TAB1 TAB1 TAB2 TAB2 XTABS TAB3 NL1 ONLRET|CR1 NL2 NL1 --- end excerpt -------------------------------------------------------- the above code example from BSD talk.c will successfully compile and run on the SGI when modified to the following: --- begin excerpt from talk.c ported to SGI ---------------------------- struct termio tty; ioctl(0, TCGETA, &tty); my_win.cerase = tty.c_cc[VERASE]; my_win.kill = tty.c_cc[VKILL]; if (tty.c_cc[VWERASE] == (char) -1) my_win.werase = '\027'; /* control W */ else my_win.werase = tty.c_cc[VWERASE]; --- end excerpt ------------------------------------------------------- clearly, ports of more extensive tty code could be done with the above information. talk.c is not heavy on tty control so the port ended up being relatively simple once the mapping from BSD's structs to SysV's structs (and the matching ioctl() calls) were found. DISCLAIMER i haven't tried a serious port, i.e. one that uses a large number of the above control characters or flags. however, an extensive comparison of termio(7) on the SGI and ttcompat(4M) on the Sun seems to suggest that most of the equivalences outlined here should work without a problem in ports from old Berkeley stuff to the SGI. -cliff cliff@research.nj.nec.com -- -- Cliff Miller, RA & ESA (research associate & existential systems-analyst) NEC Research Institute, 4 Indpendence Way, Princeton NJ 08540 cliff@research.nj.nec.com 609-951-2688 fax 609-951-2482 My note: (millert@colorado.edu) This stuff applies to hpux as well as irix except that hpux lacks VWERASE and VRPRNT. Also, here's how to do CBREAK under termio: (from my termio port of the webster client) mytermio.c_lflag &= ~ICANON; mytermio.c_cc[VMIN] = 1; mytermio.c_cc[VTIME] = 1; ioctl(0,TCSETA,&mytermio); You turn off canonical mode and make it do 1 char at a time. -- Todd C. Miller millert@Colorado.EDU ------------------------------ ** FOR YOUR REFERENCE ** The service address, to which questions about the list itself and requests to be added to or deleted from it should be directed, is: Internet: Linux-Misc-Request@NEWS-DIGESTS.MIT.EDU You can send mail to the entire list (and comp.os.linux.misc) via: Internet: Linux-Misc@NEWS-DIGESTS.MIT.EDU Linux may be obtained via one of these FTP sites: nic.funet.fi pub/OS/Linux tsx-11.mit.edu pub/linux sunsite.unc.edu pub/Linux End of Linux-Misc Digest ******************************