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