netnews@wnuxb.UUCP (Heiby) (08/30/85)
Unix Technical Digest Fri, 30 Aug 85 Volume 2 : Issue 16
Today's Topics:
file attributes (actually magic numbers)
lock file alternative
Question about initial ttyline states at first open
rwhod not working (2 msgs)
Strangness with RAW mode on 4.2 (3 msgs)
----------------------------------------------------------------------
Date: Mon, 26 Aug 85 21:56:15 PDT
From: sun!guy (Guy Harris)
Subject: file attributes (actually magic numbers)
> Does such a registry exist?
No.
> On the old pdp-11 systems, executable files used to start with
> magic numbers which also just happened to be various flavors of branches,
> all of which jumped over the header. That way you could just load an
> executable file into memory and start execution at location zero (i.e. boot
> unix) without having to worry about how long the header was. Does this
> still make any sense today?
No, not even on PDP-11s. The "407" magic number was, indeed, a branch
around the header. In V6, and all subsequent versions, a 410 or 411 magic
number was not a branch around the header; the header had the same length in
all three file types, and the code always began after the header. However,
late in V6 a field was added to the header to indicate the starting address.
If you use that, there's no need to worry about skipping over the header.
System V COFF executable images are also somewhat self-describing, although
the "UNIX header" is what's used to run the program, and it makes
essentially no use of the general multi-segment capabilities of COFF.
------------------------------
Date: Mon, 26 Aug 85 21:56:15 PDT
From: sun!guy (Guy Harris)
Subject: lock file alternative
> The most common way to do
> this is with lock files. The program checks with access(2) for the
> existence of a file. If the file is not found, then it is created. If it
> is found, then the program is assumed to be already running.
This is not guaranteed to work. The file could be created between the first
process' "access" and its "creat". You must make the test for the existence
of the file, and its creation, part of one atomic operation. You can sort
of do this by always having the file have a non-writable mode. You have the
mode in the "creat" call forbid writing. However, this won't keep the
super-user out, since they have permission to open any (non-directory) file
for writing.
If you have a system that supports the "new" 3-argument open (4.2BSD/S3/S5),
instead of a "creat" you do an "open(name, O_CREAT|O_EXCL|<open mode>, <file
mode>)". This will fail if the file exists, even if the process is running
as the super user. (Unlike "creat", the resulting file descriptor can be
open for reading and writing - why did it take until 1980 for UNIX to
support this?)
If you don't have the 3-argument open, you can use "link" instead. You have
a standard target file, in "/tmp", say. "link(<standard target>, <lock file
name>)" tests for the existence of <lock file name> and, if it doesn't
exist, makes a link of that name; this operation is atomic.
You can also use file or record locking, if your system supports it. The
"link" is the only one that works on everything including V7 and which has
no hole for the super-user.
> When the program finally finishes, it removes the lock file. Trouble is
> that if the program crashes or if the system crashes then the lock file
> is left out in the cold.
>
> [Ed note: You can put the process-id in the lock file.
> The rest is left as an exercise for the reader. RWH.]
If you ensure that the file is removed as part of the reboot procedure, you
can test whether there is a process with a given process ID by using "kill",
if you're running 4.2BSD or S3/S5 (I don't know about 4.1BSD). "kill" with
a signal 0 does everything a normal "kill" does except it doesn't deliver
any signal. If the return code is ESRCH, there is no such process;
otherwise, there is such a process.
------------------------------
Date: Mon, 26 Aug 85 21:56:15 PDT
From: sun!guy (Guy Harris)
Subject: Question about initial ttyline states at first open
> Now since I really cannot understand why anyone would want the ECHO
> bit on when opening a ttyline I thought I should ask the collected
> wizards out there if they know what the (historical) reason was for
> this bit to be set.
Yes. It's so the single-user shell (which, being /bin/sh, doesn't know
anything about tty modes) can be talked to from the console without the user
saying "why isn't it echoing my output"? There may be better solutions
(have "init" set the modes, have the default be ECHO only on the console,
etc.) but since, as is well known, nobody should rely on the terminal modes
being anything sane unless the terminal you're opening is /dev/console, you
should be setting the terminal modes in their entirety after the open; just
set them to a mode with echo off, and flush any queued-up input and output
after setting the modes.
------------------------------
Date: 28 Aug 85 10:45:21 PDT (Wed)
From: <hplabs!hp-pcd!orstcs!hakanson@orstcs>
Subject: rwhod not working
> Return-Path: tektronix!ihnp4!ulysses!smb
> Date: Sat, 24 Aug 85 18:13:37 edt
>
> The ifconfig command distributed with 4.2bsd is buggy, and can turn off
> the BROADCAST bit (and some other bits) for interfaces; this will cause
> rwhod to ignore it. You can see if this is the problem by typing
> ifconfig il0
> The response on a running system should include UP, RUNNING, BROADCAST,
> and maybe NOARP or NOTRAILERS.
ifconfig il0 returns UP and RUNNING, but nothing else, so indeed the
problem is that BROADCAST is not set. In looking through source code,
I could find nothing in /etc/ifconfig that clears BROADCAST (this is
not to say there IS nothing...); also, the il driver sets the
IFF_BROADCAST bit as it should. I suspect a buggy interface driver
(in /usr/sys/net/if.c), but don't know where to start to get that
pesky BROADCAST bit set.
> Date: Tue, 27 Aug 85 18:29:23 EDT
> From: Glen Dudek <HARVARD!dudek>
>
> As distributed, rwho will not work between machines with hostnames
> that have illegal characters. Hyphen is an illegal character.
> Just change the routine that checks for a valid hostname and
> add hyphen as a legal character.
> Glen Dudek
> Computer Facilities Manager
This is not the problem -- one machine is "orstcs" and the other
is "orstcs2" ("oregon-state" is a CSNET address, not a hostname).
Thanks to all for the information. We are narrowing it down,
but I'm still open to suggestions and/or patches....
--
Marion Hakanson CSnet: hakanson%oregon-state@csnet-relay
UUCP : {hp-pcd,tektronix}!orstcs!hakanson
------------------------------
Date: Mon, 26 Aug 85 21:56:15 PDT
From: sun!guy (Guy Harris)
Subject: rwhod not working
Yes. "rwho" only works over broadcast networks. There is a bug in
"ifconfig" that can cause the interface flags (like "broadcast") to get
smashed. See the Mt. Xinu bug list for details.
------------------------------
Date: Sat, 24 Aug 85 11:36:27 edt
From: Chris Torek <chris@maryland.ARPA>
Subject: Strangeness with RAW mode on 4.2
It's a "feature" in the C shell that occurs on machines with signed
characters. If you get a "negative" character it interprets that
as a dead tty line, and exits.
The code can be found in sh.lex.c, where I see the following (this
is from 4.3 alpha source, your code may vary):
c = bgetc();
if (c < 0) {
struct sgttyb tty;
if (wanteof)
return (-1);
/* was isatty but raw with ignoreeof yeilds problems */
if (ioctl(SHIN, TIOCGETP, (char *)&tty) == 0 &&
(tty.sg_flags & RAW) == 0) {
.
.
.
}
oops:
doneinp = 1;
reset();
}
I don't know why it's checking for !RAW, but fixing it at this
level feels kludgy. The best way to fix seems to be the one given
below.
(Now to hope it gets into 4.3....)
Chris
RCS file: RCS/sh.lex.c,v
retrieving revision 1.1
diff -c2 -r1.1 sh.lex.c
*** /tmp/,RCSt1029240 Sat Aug 24 11:28:39 1985
--- sh.lex.c Sat Aug 24 11:28:22 1985
***************
*** 1195,1199
c = fbuf[0][fseekp - fbobp];
fseekp++;
! return (c);
}
#endif
--- 1195,1199 -----
c = fbuf[0][fseekp - fbobp];
fseekp++;
! return (c & 0177);
}
#endif
***************
*** 1258,1262
c = fbuf[buf][(int) fseekp % BUFSIZ];
fseekp++;
! return (c);
}
--- 1258,1262 -----
c = fbuf[buf][(int) fseekp % BUFSIZ];
fseekp++;
! return (c & 0177);
}
------------------------------
Date: Sun, 25 Aug 85 02:27:23 edt
From: Kevin Szabo <ihnp4!watmath!watvlsi!ksbszabo>
Subject: Strangness with RAW mode on 4.2
> On my 4.2bsd VAX, under csh (but not sh), if I do "stty raw", the
>next character I type after I get the "% " back logs me out. Can anybody
>explain what is going on here?
>
>Roy Smith <allegra!phri!roy>
Ah, I think I know what this one is... I once heard that CSH just
checks whether getchar (or equivalent) returns a "less than zero" to
represent EOF. When you go into raw mode your 8 bit character (with
parity bit on) gets sign extended to a negative number... voila' CSH
thinks you have typed an EOF. I haven't looked at the code but it does
make sense. We have it fixed in our local (hacked) CSH. Our local CSH
also checks the tty state after every command, and resets it if the
state is not a "rational" one.
--
Kevin Szabo' watmath!wateng!ksbszabo (U of W VLSI Group, Waterloo, Ont, Canada)
------------------------------
Date: Sun, 25 Aug 85 11:45:06 edt
From: bowles@cbosgd.ATT.UUCP (Jeff Bowles)
Subject: Strangness with RAW mode on 4.2
Check out whether or not sign extension in the I/O library that "csh" is
using you is killing you. Since that version of 'csh' probably just tests
for an input character being less than 0 (as opposed to EOF), then "stty raw"
combined with the parity of the terminal might cause it to look like you're
getting negative characters as input.
In short, check the parity on the terminal (see if changing it helps) and
then start poking through the "csh" source for the I/O routines. A test for
equality to EOF (and a subsequent bitwise mask if not) might be called for...
Jeff Bowles
Lisle, IL
------------------------------
End of Unix Technical Digest
******************************
--
Ronald W. Heiby / netnews@wnuxb.UUCP
AT&T Information Systems, Inc., Lisle, IL (CU-D21)