Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!emory!hubcap!gatech!mcnc!uvaarpa!haven!adm!news From: IN% Postmaster@VAX1.Mankato.MSUS.EDU %MKVAX1.DECNET@msus1.bitnet (PMDF Mail Server) Newsgroups: comp.unix.wizards Subject: Undeliverable mail: SMTP delivery failure Message-ID: <26045@adm.brl.mil> Date: 18 Feb 91 08:22:40 GMT Sender: news@adm.brl.mil Lines: 900 Return-path: Date: Sat, 16 Feb 1991 14:12 CST From: PMDF Mail Server Subject: Undeliverable mail: SMTP delivery failure To: "MSUS1::IN%\"UNIX-WIZARDS@BRL.MIL\""@VAX1.Mankato.MSUS.EDU Message-id: <20B31A6AA0207F88@VAX1.Mankato.MSUS.EDU> The message could not be delivered to: Addressee: BD6@MKATT1.MANKATO.MSUS.EDU Reason: Illegal host/domain name found. ---------------------------------------- Received: from DECNET-MAIL by VAX1.Mankato.MSUS.EDU with PMDF#10000; Fri, 15 Feb 1991 05:57 CST Date: Fri, 15 Feb 1991 05:57 CST From: "MSUS1::IN%\"UNIX-WIZARDS@BRL.MIL\""@VAX1.Mankato.MSUS.EDU Subject: UNIX-WIZARDS Digest V12#019 To: BD6@MKATT1.MANKATO.MSUS.EDU Message-id: <1267ABF5C0206670@VAX1.Mankato.MSUS.EDU> X-VMS-To: "Brian D. Goecke" Return-path: Received: from NDSUVM1.BITNET (MAILER@NDSUVM1) by MSUS1.MSUS.EDU with PMDF#10130; Fri, 15 Feb 1991 05:55 CST Received: by NDSUVM1 (Mailer R2.07) id 1371; Fri, 15 Feb 91 05:51:46 CST Date: Fri, 15 Feb 91 05:45:06 EST From: Mike Muuss The Moderator Subject: UNIX-WIZARDS Digest V12#019 Sender: Unix-Wizards Mailing List To: "Brian D. Goecke" Reply-to: UNIX-WIZARDS@BRL.MIL Message-id: <1230A50BC0004B3E@MSUS1.MSUS.EDU> X-To: UNIX-WIZARDS@BRL.MIL UNIX-WIZARDS Digest Fri, 15 Feb 1991 V12#019 Today's Topics: Really serious security hole in Microport Unix (Re: SECURITY BUG IN INTERACTIVE UNIX SYSV386) Re: SIGCONT occurs after a SIGTERM Re: Help! There's a slash '/' in my filename. re: How to read v6 distribution tapes? Re: Slashes in file names Re: Loading and Executing Object Code at Runtime Some Wizardry in need V7/BSD vs. S3/S5/POSIX tty drivers (was Re: gettytab, entries f0, f1 & f2) Re: dynamic linking C code with ld link editor SCO Mailing List How to get remote ethernet address? Counting FLOPS Putenv() & Getenv() Bug ? ----------------------------------------------------------------- From: Bill Subject: Really serious security hole in Microport Unix (Re: SECURITY BUG IN INTERACTIVE UNIX SYSV386) Date: 13 Feb 91 17:03:16 GMT Followup-To: comp.unix.sysv386 To: unix-wizards@sem.brl.mil [I've crossposted this widely because there should be a lot of people who care about this; however, I've directed followups to comp.unix.sysv386.] Interactive's Unix isn't the only one with a really serious security hole. Microport 3.0e, and possibly others from Microport, has an equally awful hole and it is unfixable without kernel hacking. Microport knows about it since I told them about it; I don't know what, if anything, they are going to do about it. If anyone out there wants information on this bug, I will send it to you. Also, I have created a replacement for the offending kernel module of 3.0e and can send that. However, I will only send these to root@yoursite and only if I think that the path to your site is reasonably secure. If you are at the end of an insecure (in my opinion, and I won't change it) path and you still want this information, I will arrange a direct uucp connection to send it. If that won't work, I'll try to arrange something. I won't immediately describe the bug on the net in order to give admins a chance to fix their systems before the crackers get a whack at it. I can't even describe the general area that this bug compromises without making it too easy to trigger it. In a few weeks, after the expected deluge of "what *is* that bug" messages, I will post the informational message I'm sending out. -- Consider said various vicious and incendiary comments about brain dead programmers and inadequate QA. These bugs should *never* have made it out the door and, having done so, they should never have lasted as long as they have. Of course, we can't blame the guys at Interactive and Microport too much; they have had the example (and largely uncomment code) of those guys who gave us the still unfixed (or so I hear) System V inode bug. ----------------------------- From: Heiko Blume Subject: Re: SIGCONT occurs after a SIGTERM Date: 13 Feb 91 21:31:10 GMT To: unix-wizards@sem.brl.mil richard@locus.com (Richard M. Mathews) writes: >The solution is don't catch SIGCONT. Your SIGTSTP handler knows when >the program resumes anyway because the line after the "kill" which >caused it to suspend itself will not be reached until the program is >resumed. which fails miserably when you get the uncatchable SIGSTOP. *yes*, i do use SIGSTOP, there are programs that disable the SIGTSTP feature, and i won't let those go unsuspended. -- Heiko Blume <-+-> src@scuzzy.in-berlin.de <-+-> (+49 30) 691 88 93 public source archive [HST V.42bis]: scuzzy Any ACU,f 38400 6919520 gin:--gin: nuucp sword: nuucp uucp scuzzy!/src/README /your/home ----------------------------- From: Steve Alter Subject: Re: Help! There's a slash '/' in my filename. Date: 14 Feb 91 05:41:03 GMT To: unix-wizards@sem.brl.mil At last, a package that avoids this problem altogether! I'm installing and testing the uShare software from Information Presentation Technologies, Inc. It provides, among other things, an AppleShare Server daemon for SunOS systems. I don't know if anybody else does this (yet) but uShare prevents the '/' from getting into the filename in the first place. When you create a file from a Mac in a uShare AppleShare volume, any characters that Unix might not like (slashes, control characters, bytes with the 8th bit, etc.) are converted into some strange notation (possibly hexadecimal digits) and prefixed with a ':'. Since the colon is invalid as part of a Mac filename (it's used to separate folder names in a path and the "Save File" dialog either ignores it or turns it into a hyphen) it's certainly available to protect the filename on the Unix side. -- Steve Alter {philabs,psivax,pyramid,quad1,rdlvax,retix,rutgers}!ttidca!alter Transaction Technology Inc. a subsidiary of Citicorp (213) 450-9111 x2541 ----------------------------- From: Barry Shein Subject: Re: Help! There's a slash '/' in my filename. Date: 14 Feb 91 09:33:17 GMT Sender: Barry Shein To: unix-wizards@sem.brl.mil From: s082@brems.ii.uib.no >Just one thing: Why would anyone want a slash (or any such character) a >filename in the first place? Perhaps the file name was in Norwegian? :-) (it's usually another machine, like a macintosh, using NFS to the unix system and creating a file name like "Expense 12/2/91" which is legal and common on macs.) Doesn't norwegian use o-slash and all that? -- -Barry Shein Software Tool & Die | bzs@world.std.com | uunet!world!bzs Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD ----------------------------- From: Dennis Ritchie Subject: re: How to read v6 distribution tapes? Date: 14 Feb 91 06:05:35 GMT To: unix-wizards@sem.brl.mil Roy Smith wondered about how to look at v6, which exist on tape as RK05 disk images. Here's how we do it. It's instructive of something--I'm not sure quite what, but it makes an interesting demo, and it is a useful way to keep these archives. We transferred the disk images to big single files. Norman Wilson wrote a file server that understands the v6 disk format (512-byte disk blocks, 32-byte inodes, 16-bit disk addresses). Thus we can mount this disk image as a file system and poke around in it. Incidentally, we still have a few vax 11/750s, with the pdp-11 compatibility feature. So, from such a machine I can do cd /n/bowell/usr/src/history/v6/bin/bin # move to v6 /bin compat sh # start v6 shell and get a `%' prompt. These commands change to a directory on another machine, which contains an interpreted Sixth Edition file system, and run the Sixth Edition shell. Many of the commands there work. E.g. % ./size sh 4992+880+1408=7280 (16160) % ./date Thu Feb 14 00:46:32 EST 1991 % ./dc 10k2vp 1.4142135623 Doing this induces a somewhat creepy feeling. Dennis Ritchie dmr@research.att.com att!research!dmr ----------------------------- From: Sean Eric Fagan Subject: Re: Slashes in file names Date: 14 Feb 91 09:18:53 GMT To: unix-wizards@sem.brl.mil In article <1991Feb14.070512.24190@athena.mit.edu> scs@adam.mit.edu writes: >If the protocol doesn't include an error return of "I can't >create a file of that name" (not surprising; doesn't >define that specific error either, although it probably should), It does. BSD has been using EINVAL to indicate an illegal filename (8-bit set in one or more of the characters), I believe. Thus, I think that's the error that should have been used, if possible. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others. ----------------------------- From: Barry Shein Subject: Re: Loading and Executing Object Code at Runtime Date: 14 Feb 91 09:43:21 GMT Sender: Barry Shein To: unix-wizards@sem.brl.mil >I'm wondering how to load an object file (my_functions.o) at execution >time and execute a function contained therein. I know this is possible >since many flavors of LISP allow you to compile your functions and then >load the compiled versions later. > >If it's in TFM, could someone point me in the right direction, or, if it's >trivially simple, could someone please explain how to go about it? It's not trivially simple by any means and can be quite subtle to get right (e.g. loading multiple functions which reference each other and external functions.) It also is heavily dependent on the particular version of Unix, this is not portable, although one solution might work on several different unixes. BSD-based systems will use "ld -A" for starters. Encore had a routine to do this which made it relatively easy (dynaload(), which I think originated at AT&T but was never made part of the regular distribution? Or do I say this every two years when it comes up and someone corrects me that it's original to Encore? Anyhow.) In theory you should be able to do this on any Unix system, barring hideous ideosyncractic restrictions, it's mostly a matter of how much of a link-editor you might have to implement yourself. For starters, if you had a trivial routine that had no external references you can usually just read it into a malloc'd array of bytes from the .o and jump to it. It's the external references that make this harder than that, you have to resolve the externals against any which are already in the running image (e.g. printf) and load in any externals from the libraries (e.g. libc.a) which aren't. Your best bet is to find a piece of code which does this and read it. KCL does this and is available in source from various FTP sources. -- -Barry Shein Software Tool & Die | bzs@world.std.com | uunet!world!bzs Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD ----------------------------- From: Melinda Shore Subject: Re: Loading and Executing Object Code at Runtime Date: 14 Feb 91 18:29:25 GMT To: unix-wizards@sem.brl.mil In article bzs@world.std.com (Barry Shein) writes: >In theory you should be able to do this on any Unix system, barring >hideous ideosyncractic restrictions A quite widespread hideous idiosyncratic restriction is that on some architectures, notably the 386, you can't execute out of data space. It's sometimes possible to work around it by playing games with remapping memory, but only if you have kernel support (as with, say, Mach). -- Software longa, hardware brevis Melinda Shore shore@mtxinu.com mt Xinu ..!uunet!mtxinu.com!shore ----------------------------- From: Suresh Subramanian Subject: Some Wizardry in need Keywords: Sockets, Signals. Date: 14 Feb 91 18:54:26 GMT Sender: newsdaemon@shlump.nac.dec.com To: unix-wizards@sem.brl.mil The scenario goes like this if (!fork()) { fd = socket(.....); /* Unix domain */ bind and listen for connection accept(...) close(0) dup2(fd,0); close(1); dup2(fd,1); close(2); dup2(fd,2); execl("tip", "tip", args, (char *)0); /* standard unix tip, */ } else { sock = socket(...) connect(...); parent process goes on and exits. } (SIGCLD is also installed for notifying child's death) The main program is kind of a supervisor. Keeps waiting for user input and does appropriate actions. The problem I am facing is this:- 1) When a user wants to login to a another machine he calls the above mentioned function. I go ahead and exec tip and wait for tip to make the connection and send me a "login:" prompt. I get it and all goes well. But if the number dialled by tip is a lat then I will not get the standard login prompt. But instead I will get the LAT prompt and tip will be waiting for input from the user. Now the supervisor (that's me) should know that I have to get the input from the user and send it to tip. But I don't know that since I did not get the standard "login: " prompt but a LAT prompt. I cannot forsee all possible lat prompts. An elegant solution would be to get signal from tip, when it is waiting to do IO. I know there is SIGIO to do that. But I have execed tip within a child process. So the function address that I pass to signal system call before execing tip is now meaningless within the tip program. A solution is to modify tip to send SIGIO. But is there any other way to get the job done? Many Thanks for any insight Suresh ----------------------------- From: Guy Harris Subject: V7/BSD vs. S3/S5/POSIX tty drivers (was Re: gettytab, entries f0, f1 & f2) Date: 14 Feb 91 21:28:32 GMT Followup-To: comp.unix.programmer To: unix-wizards@sem.brl.mil (Not really a wizard-level question these days, and not really involved with UNIX internals, and not Ultrix-specific; this long discourse should probably be stuck in an FAQ list some day, at least until the POSIX tty driver conquers the UNIX world and we can all *finally* forget about the V7 driver and its descendants....) >All bsd-based Unix-Implementations of getty (at least as far as known to me) >support gettytab attributes f0, f1 and f2. > >According to TFM(gettytab) they take numeric values, where f0, f1 & f2 >represent the tty mode flags "to write messages", "to read login name", >and "to leave terminal in". > >"... Terminal modes to be used for the output of the message, >for input of the login name, and to leave ther terminal set as upon >completion, are derived from the Boolean flags specified. If the derivation >should prove inadequate, any (or all) of these three may be overridden >with one of the f0, f1, or f2 numeric specifications, which can be >used to specify (usually in octal, with a leading 0) the exact values >of the flags. Local (new tty) flags are set in the top 16 bits of this >(32-bit) value. ..." [ From Dec Ultrix V4.0 Ref. Man. Vol 6 ] > >Now my question: how do the terminal mode flags (as know from termio or stty) >correspond to the bits in f0 (or f1, f2)? > >Obviously it cannot be a 1:1 corresponency, since the struct termio >contains 4 short values (c_iflag, c_oflag, c_cflag, c_lflag), >or - in other words - 64 bits. > >Any ideas/experiences anyone? There are two general flavors of UNIX terminal drivers: "V7ish" and "System III"ish. (We ignore "V6ish" terminal drivers, as they're really ancient and obsolete.) "V7ish" terminal drivers have the "ioctl" functions TIOCGETP, TIOCSETP, TIOCSETN, TIOCGETC, and TIOCSETC, and may have other functions. TIOCGETP, TIOCSETP, and TIOCSETN use "struct sgtty", which includes the member "sg_flags", which is a "short", generally 16 bits. Some systems with "V7ish" terminal drivers have the functions TIOCLBIS, TIOCLBIC, TIOCLSET, and TIOCLGET, which use a "local mode word", with 16 bits. "System III"ish terminal drivers have one or more of: the "ioctl" functions TCGETA, TCSETA, TCSETAW, and TCSETAF; the "ioctl" functions TCGETS, TCSETS, TCSETSW, and TCSETSF; the POSIX functions "tcgetattr()" and "tcsetattr()". TCGETA, TCSETA, TCSETAW, and TCSETAF use "struct termio", which includes the members "c_iflag", "c_oflag", "c_cflag", and "c_lflag"; in "struct termio", they are all "unsigned short", generally 16 bits. TCGETS, TCSETS, TCSETSW, and TCSETSF, as well as "tcgetattr()" and "tcsetattr()", use "struct termios", which also includes the members "c_iflag", "c_oflag", "c_cflag", and "c_lflag"; in "struct termios", they are all "unsigned long", or "tcflag_t", generally 32 bits. The "f0", "f1", and "f2" flags in "gettytab" are the 16 bits from "sgtty.sg_flags", plus the 16 bits from the "local mode word", as described above (the "local mode word" flags are in the upper 16 bits). Some systems support both interfaces, either by some subterfuge such as having multiple line disciplines, or by translating one style of "ioctl" into another. SunOS 4.x and S5R4 do the latter; they support a "System III"ish terminal driver as their native tty driver, with a streams module that translates "V7ish" "ioctl"s into "System III"ish "ioctl"s. The underlying "System III"ish tty driver has been extended to support a bunch of BSDish features. Here's stuff from the manual page for that streams module, which gives some indication of how the modes are mapped. Note that *NOT* all systems with "System III"ish tty drivers have all the modes described below; if your system doesn't document it, it probably doesn't have it. Some fairly old systems with "V7ish" tty drivers may not have all the BSD features listed either. The basic ioctl calls use the sgttyb structure defined by : struct sgttyb { char sg_ispeed; char sg_ospeed; char sg_erase; char sg_kill; short sg_flags; }; The sg_ispeed and sg_ospeed fields describe the input and output speeds of the device, and reflect the values in the c_cflag field of the termio structure. The sg_erase and sg_kill fields of the argument structure specify the erase and kill characters respectively, and reflect the values in the VERASE and VKILL members of the c_cc field of the termio structure. 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 If previous TIOCLSET or TIOCLBIS ioctl calls have not selected LITOUT or PASS8 mode, and if RAW mode is not selected, the ISTRIP flag is set in the c_iflag field of the termio structure, and the EVENP and ODDP flags control the parity of characters sent to the terminal and accepted from the terminal: 0 Parity is not to be generated on output or checked on input; the character size is set to CS8 and the PARENB flag is cleared in the c_cflag field of the termio structure. EVENP Even parity characters are to be generated on output and accepted on input; the INPCK flag is set in the c_iflag field of the termio struc- ture, the character size is set to CS7 and the PARENB flag is set in the c_cflag field of the termio structure. ODDP Odd parity characters are to be generated on output and accepted on input; the INPCK flag is set in the c_iflag field, the character size is set to CS7 and the PARENB and PARODD flags are set in the c_cflag field of the termio struc- ture. EVENP|ODDP Even parity characters are to be generated on output and characters of either parity are to be accepted on input; the INPCK flag is cleared in the c_iflag field, the character size is set to CS7 and the PARENB flag is set in the c_cflag field of the termio structure. The RAW flag disables all output processing (the OPOST flag in the c_oflag field, and the XCASE flag in the c_lflag field, are cleared in the termio structure) and input pro- cessing (all flags in the c_iflag field other than the IXOFF and IXANY flags are cleared in the termio structure). 8 bits of data, with no parity bit, are accepted on input and generated on output; the character size is set to CS8 and the PARENB and PARODD flags are cleared in the c_cflag field of the termio structure. The signal-generating and line- editing control characters are disabled by clearing the ISIG and ICANON flags in the c_lflag field of the termio struc- ture. The CRMOD flag turn input RETURN characters into NEWLINE characters, and output and echoed NEWLINE characters to be output as a RETURN followed by a LINEFEED. The ICRNL flag in the c_iflag field, and the OPOST and ONLCR flags in the c_oflag field, are set in the termio structure. The LCASE flag maps upper-case letters in the ASCII charac- ter set to their lower-case equivalents on input (the IUCLC flag is set in the c_iflag field), and maps lower-case letters in the ASCII character set to their upper-case equivalents on output (the OLCUC flag is set in the c_oflag field). Escape sequences are accepted on input, and gen- erated on output, to handle certain ASCII characters not supported by older terminals (the XCASE flag is set in the c_lflag field). Other flags are directly mapped to flags in the termio structure: sg_flags flags in termio structure CBREAK complement of ICANON in c_lflag field ECHO ECHO in c_lflag field TANDEM IXOFF in c_iflag field Another structure associated with each terminal specifies characters that are special in both the old Version 7 and the newer 4BSD terminal interfaces. The following structure is defined by : 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) */ }; The characters are mapped to members of the c_cc field of the termio structure as follows: tchars c_cc index t_intrc VINTR t_quitc VQUIT t_startc VSTART t_stopc VSTOP t_eofc VEOF t_brkc VEOL Also associated with each terminal is a local flag word, specifying flags supported by the new 4BSD terminal inter- face. Most of these flags are directly mapped to flags in the termio structure: local flags flags in termio structure LCRTBS not supported LPRTERA ECHOPRT in the c_lflag field LCRTERA ECHOE in the c_lflag field LTILDE not supported LTOSTOP TOSTOP in the c_lflag field LFLUSHO FLUSHO in the c_lflag field LNOHANG CLOCAL in the c_cflag field LCRTKIL ECHOKE in the c_lflag field LCTLECH CTLECH in the c_lflag field LPENDIN PENDIN in the c_lflag field LDECCTQ complement of IXANY in the c_iflag field LNOFLSH NOFLSH in the c_lflag field Another structure associated with each terminal is the ltchars structure which defines control characters for the new 4BSD terminal interface. Its structure is: 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 */ }; The characters are mapped to members of the c_cc field of the termio structure as follows: ltchars c_cc index t_suspc VSUSP t_dsuspc VDSUSP t_rprntc VREPRINT t_flushc VDISCARD t_werasc VWERASE t_lnextc VLNEXT IOCTLS ttcompat responds to the following ioctl calls. All others are passed to the module below. TIOCGETP The argument is a pointer to an sgttyb struc- ture. The current terminal state is fetched; the appropriate characters in the terminal state are stored in that structure, as are the input and output speeds. The values of the flags in the sg_flags field are derived from the flags in the terminal state and stored in the structure. TIOCSETP The argument is a pointer to an sgttyb struc- ture. The appropriate characters and input and output speeds in the terminal state are set from the values in that structure, and the flags in the terminal state are set to match the values of the flags in the sg_flags field of that structure. The state is changed with a TCSETSF ioctl, so that the interface delays until output is quiescent, then throws away any unread char- acters, before changing the modes. TIOCSETN The argument is a pointer to an sgttyb struc- ture. The terminal state is changed as TIOCSETP would change it, but a TCSETS ioctl is used, so that the interface neither delays nor discards input. TIOCHPCL The argument is ignored. The HUPCL flag is set in the c_cflag word of the terminal state. TIOCFLUSH The argument is a pointer to an int variable. If its value is zero, all characters waiting in input or output queues are flushed. Otherwise, the value of the int is treated as the logical OR of the FREAD and FWRITE flags defined by ; if the FREAD bit is set, all char- acters waiting in input queues are flushed, and if the FWRITE bit is set, all characters waiting in output queues are flushed. TIOCSTOP The argument is ignored. Output is stopped as if the STOP character had been typed. TIOCSTART The argument is ignored. Output is restarted as if the START character had been typed. TIOCGETC The argument is a pointer to an tchars struc- ture. The current terminal state is fetched, and the appropriate characters in the terminal state are stored in that structure. TIOCSETC The argument is a pointer to an tchars struc- ture. The values of the appropriate characters in the terminal state are set from the charac- ters in that structure. TIOCLGET The argument is a pointer to an int. The current terminal state is fetched, and the values of the local flags are derived from the flags in the terminal state and stored in the int pointed to by the argument. TIOCLBIS The argument is a pointer to an int whose value is a mask containing flags to be set in the local flags word. The current terminal state is fetched, and the values of the local flags are derived from the flags in the terminal state; the specified flags are set, and the flags in the terminal state are set to match the new value of the local flags word. TIOCLBIC The argument is a pointer to an int whose value is a mask containing flags to be cleared in the local flags word. The current terminal state is fetched, and the values of the local flags are derived from the flags in the terminal state; the specified flags are cleared, and the flags in the terminal state are set to match the new value of the local flags word. TIOCLSET The argument is a pointer to an int containing a new set of local flags. The flags in the termi- nal state are set to match the new value of the local flags word. TIOCGLTC The argument is a pointer to an ltchars struc- ture. The values of the appropriate characters in the terminal state are stored in that struc- ture. TIOCSLTC The argument is a pointer to an ltchars struc- ture. The values of the appropriate characters in the terminal state are set from the charac- ters in that structure. ----------------------------- From: Guy Harris Subject: Re: dynamic linking C code with ld link editor Date: 14 Feb 91 21:39:52 GMT To: unix-wizards@sem.brl.mil >I had this problem for several months until (after much hacking) I got my >dynamic loaders to work with Postgres. It is a rather different idea than >shared libraries - the idea is to load and execute a function (whose name is >unknown beforehand) in an object file given by the user. Different idea, but the SunOS 4.1/S5R4 implementation of it (and, I think, the OSF/1 implementation of it) uses a lot of stuff from the shared library mechanism in the OSes in question. If you're on one of those systems, you don't have to know about executable file formats, or all the other obscure stuff; just use the dynamic loading mechanism that comes with the OS. ----------------------------- From: Dave Armbrust Subject: SCO Mailing List Date: 14 Feb 91 22:45:01 GMT To: unix-wizards@sem.brl.mil The Santa Cruz Operation mailing list Charter: For exchange of information and discussions regarding all products from Santa Cruz operations. This group will be beneficial to any one interested or currently using SCO products. This mailing list is a single area that discussions and information can be exchanged regarding ALL SCO products. This mailing is independent of any existing news groups. If you are currently using SCO products, interested in products from SCO or work for Santa Cruz Operations I encourage you to join the SCO mailing list. Currently there are 300 sites that subscribe to the list. The SCO mailing list is located on the uunet host. Send all articles or discussions to the address: sco-list@uunet.uu.net Please send change requests to sco-list-request@uunet.uu.net. If you wish to be added to this list please follow these instructions. IT IS IMPORTANT THAT THESE INSTRUCTIONS ARE FOLLOWED AS THE PROCESS IS AUTOMATED. 1) Mail your add request to sco-list-request@uunet. Do not send your request to sco-list@uunet.uu.net as this is the address to post all articles to. 2) Include the address you wish to received the mailing at in the body of the mail message. Example to add the address dma@pcssc.com include in the body of the message the following: Add: dma@pcssc.com Note the word add starts with a capital `A` and is the first word on the line. It is also followed by a colon ':', a single blank space, an address and then a new line. Be sure to include the `:` and the blank. Do not follow the address with any comments. Only internet addresses are accepted, Bang paths are not allowed. Do not put the add request in the subject line as this will be ignored. 3) Once our system receives your request you will receive an acknowledgment. You will then start to get all articles posted to uunet!sco-list. 4) If you do not receive the acknowledgment and postings right away do not send a alternate address path. You may end up getting two copies of all posting using both paths. Instead mail myself at dma@pcssc.com and ask if I got the original request. ----------------------------------------------------------------------------- Dave Armbrust | PC Software Systems | dma@pcssc.com or 4370 S Tamiami Trail | owner-sco-list@uunet.uu.net Sarasota, FL 34231-3400 | Phone: (813)922-8857 ----------------------------- From: Lynn Wallace Subject: How to get remote ethernet address? Keywords: ethernet address remote Date: 15 Feb 91 00:04:14 GMT To: unix-wizards@sem.brl.mil We use dedicated ethernet connections between machines, meaning a machine on each end of a cable with no other connections. The system I am writing (or attempting to :-) a driver for will be connected to various machines, sometimes "right off the assembly line". Is there a way to obtain the remote's ethernet address (vs. internet address; it's a low-level protocol) from software so the user doesn't have to flip through a manual, eyeball a card or peek memory to get it? Reply via e-mail please, as I don't usually follow these groups. Thanks! -- Lynn Wallace |I am not an official representative of Evans and Sutherland Computer Corp.| <- E&S. Or for that matter, unofficial. Salt Lake City, UT 84108 |Internet: lwallace@javelin.sim.es.com War not make one great! -- Yoda ----------------------------- From: Rouben Rostamian Subject: Counting FLOPS Date: 15 Feb 91 00:40:44 GMT Sender: newspost@umbc3.umbc.edu To: unix-wizards@sem.brl.mil How does one count the number of floating point operations (flops) during the execution of a C program? I guess it is possible to trace manually all loops and function calls and iterations and recursions, etc., and add them up, but that will easily gets out of hand for a half-way complicated program. Are there automatic tools for doing this? I am primarily interested in a solution which will work under RISC Ultrix, if that matters. Rouben Rostamian -- Rouben Rostamian Telephone: (301) 455-2458 Department of Mathematics and Statistics e-mail: University of Maryland Baltimore County bitnet: rostamian@umbc.bitnet Baltimore, MD 21228, U.S.A. internet: rouben@math9.math.umbc.edu ----------------------------- From: Ivan Borzieri Subject: Putenv() & Getenv() Bug ? Date: 15 Feb 91 10:15:44 GMT Sender: news@olivea.atc.olivetti.com To: unix-wizards@sem.brl.mil Hi, I URGENTLY need this information : I wrote two c modules called by a fortran main. in the first c module I call the system function "putenv()" which should set a variable in the environment. In the second c module I call the system function "getenv()" to read the value of the previous set variable. The value returned by getenv() is NULL, id est, that variable doesn't exist. Now my question is : is this right ? I know that in C-Shell scripts, when you set variables you loose them as you exit the script. Is it the same or this is a operating system bug ? The system is SCO Unix System V 3.2 Thanks, Ivan Borzieri ----------------------------- End of UNIX-WIZARDS Digest **************************