Undeliverable mail: SMTP delivery failure

IN%Postmaster at VAX1.Mankato.MSUS.EDU%MKVAX1.DECNET IN%Postmaster at VAX1.Mankato.MSUS.EDU%MKVAX1.DECNET
Mon Feb 18 19:22:40 AEST 1991


Return-path: <postmaster at VAX1.Mankato.MSUS.EDU>
Date: Sat, 16 Feb 1991 14:12 CST
From: PMDF Mail Server <Postmaster at VAX1.Mankato.MSUS.EDU>
Subject: Undeliverable mail: SMTP delivery failure
To: "MSUS1::IN%\"UNIX-WIZARDS at BRL.MIL\""@VAX1.Mankato.MSUS.EDU
Message-id: <20B31A6AA0207F88 at VAX1.Mankato.MSUS.EDU>

The message could not be delivered to:

Addressee: BD6 at 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 at BRL.MIL\""@VAX1.Mankato.MSUS.EDU
Subject: UNIX-WIZARDS Digest  V12#019
To: BD6 at MKATT1.MANKATO.MSUS.EDU
Message-id: <1267ABF5C0206670 at VAX1.Mankato.MSUS.EDU>
X-VMS-To: "Brian D. Goecke" <bd6%MKVAX1.DECNET at MSUS1.BITNET>

Return-path: <UNIX-WIZ at NDSUVM1.BITNET>
Received: from NDSUVM1.BITNET (MAILER at 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 <Unix-Wizards-Request at BRL.MIL>
Subject: UNIX-WIZARDS Digest  V12#019
Sender: Unix-Wizards Mailing List <UNIX-WIZ at NDSUVM1.BITNET>
To: "Brian D. Goecke" <bd6%MKVAX1.DECNET at MSUS1.BITNET>
Reply-to: UNIX-WIZARDS at BRL.MIL
Message-id: <1230A50BC0004B3E at MSUS1.MSUS.EDU>
X-To:         UNIX-WIZARDS at 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 <bill at franklin.com>
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 at 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 at 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 <src at scuzzy.in-berlin.de>
Subject: Re: SIGCONT occurs after a SIGTERM
Date: 13 Feb 91 21:31:10 GMT
To:       unix-wizards at sem.brl.mil
 
richard at 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 at 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 <alter at ttidca.tti.com>
Subject: Re: Help!  There's a slash '/' in my filename.
Date: 14 Feb 91 05:41:03 GMT
To:       unix-wizards at 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        <alter at ttidca.tti.com>
{philabs,psivax,pyramid,quad1,rdlvax,retix,rutgers}!ttidca!alter
Transaction Technology Inc. a subsidiary of Citicorp  (213) 450-9111 x2541
 
-----------------------------
 
From: Barry Shein <bzs at world.std.com>
Subject: Re: Help!  There's a slash '/' in my filename.
Date: 14 Feb 91 09:33:17 GMT
Sender: Barry Shein <bzs at world.std.com>
To:       unix-wizards at sem.brl.mil
 
 
From: s082 at 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 at world.std.com          | uunet!world!bzs
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD
 
-----------------------------
 
From: Dennis Ritchie <dmr at alice.att.com>
Subject: re: How to read v6 distribution tapes?
Date: 14 Feb 91 06:05:35 GMT
To:       unix-wizards at 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 at research.att.com
	att!research!dmr
 
-----------------------------
 
From: Sean Eric Fagan <sef at kithrup.com>
Subject: Re: Slashes in file names
Date: 14 Feb 91 09:18:53 GMT
To:       unix-wizards at sem.brl.mil
 
In article <1991Feb14.070512.24190 at athena.mit.edu> scs at 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; <errno.h> 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 at 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 <bzs at world.std.com>
Subject: Re: Loading and Executing Object Code at Runtime
Date: 14 Feb 91 09:43:21 GMT
Sender: Barry Shein <bzs at world.std.com>
To:       unix-wizards at 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 at world.std.com          | uunet!world!bzs
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD
 
-----------------------------
 
From: Melinda Shore <shore at mtxinu.com>
Subject: Re: Loading and Executing Object Code at Runtime
Date: 14 Feb 91 18:29:25 GMT
To:       unix-wizards at sem.brl.mil
 
In article <BZS.91Feb14044321 at world.std.com> bzs at 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 at mtxinu.com
mt Xinu                              ..!uunet!mtxinu.com!shore
 
-----------------------------
 
From: Suresh Subramanian <suresh at lama.enet.dec.com>
Subject: Some Wizardry in need
Keywords: Sockets, Signals.
Date: 14 Feb 91 18:54:26 GMT
Sender: newsdaemon at shlump.nac.dec.com
To:       unix-wizards at 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 <guy at auspex.auspex.com>
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 at 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
     <sys/ioctl.h>:
 
          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 <sys/ioctl.h>:
 
          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
                 <sys/file.h>; 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 <guy at auspex.auspex.com>
Subject: Re: dynamic linking C code with ld link editor
Date: 14 Feb 91 21:39:52 GMT
To:       unix-wizards at 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 <dma at pcssc.com>
Subject: SCO Mailing List
Date: 14 Feb 91 22:45:01 GMT
To:       unix-wizards at 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 at uunet.uu.net
 
Please send change requests to sco-list-request at 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 at uunet.  Do not send
your request to sco-list at 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 at pcssc.com include
in the body of the message the following:
 
Add: dma at 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 at pcssc.com and ask if I
got the original request.
 -----------------------------------------------------------------------------
Dave Armbrust               |
PC Software Systems         |     dma at pcssc.com or
4370 S Tamiami Trail        |     owner-sco-list at uunet.uu.net
Sarasota, FL 34231-3400     |     Phone: (813)922-8857
 
-----------------------------
 
From: Lynn Wallace <lwallace at javelin.es.com>
Subject: How to get remote ethernet address?
Keywords: ethernet address remote
Date: 15 Feb 91 00:04:14 GMT
To:       unix-wizards at 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 at javelin.sim.es.com
			War not make one great! -- Yoda
 
-----------------------------
 
From: Rouben Rostamian <rouben at math9.math.umbc.edu>
Subject: Counting FLOPS
Date: 15 Feb 91 00:40:44 GMT
Sender: newspost at umbc3.umbc.edu
To:       unix-wizards at 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 at umbc.bitnet
Baltimore, MD 21228,  U.S.A.              internet: rouben at math9.math.umbc.edu
 
-----------------------------
 
From: Ivan Borzieri <borzieri at king.ico.olivetti.com>
Subject: Putenv() & Getenv() Bug ?
Date: 15 Feb 91 10:15:44 GMT
Sender: news at olivea.atc.olivetti.com
To:       unix-wizards at 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
**************************



More information about the Comp.unix.wizards mailing list