netnews@wnuxb.UUCP (Heiby) (08/24/85)
Unix Technical Digest Sat, 24 Aug 85 Volume 2 : Issue 15
Today's Topics:
4.2bsd 'talk' problem
[f]chmod on 4.2BSD (2 msgs)
Data compression program available
Digest V2 #14: Disk Quotas
file attributes (actually magic numbers)
lock file alternative
Question about initial ttyline states at first open
rwhod doesn't
Strangness with RAW mode on 4.2
----------------------------------------------------------------------
Date: Thu, 8 Aug 85 13:59:18 edt
From: Chris Torek <chris@maryland.ARPA>
Subject: 4.2bsd 'talk' problem
The bug is not in talk, it's in curses. Curses has a 256 byte
array into which it stores the string data from your termcap. The
array should be *at least* 1024 bytes. If you check your termcaps,
your hardwired terminals probably have fewer bytes to store than
your dialup terminal.
(If I remember correctly, the array is declared in "cr_tty.c" (which
is of course in /usr/src/usr.lib/libcurses).)
Chris
------------------------------
Date: Monday, 12 Aug 85 07:29:25 PDT
From: ihnp4!tektronix!tektools!jerryp
Subject: [f]chmod on 4.2BSD
In article <623@wnuxb.UUCP> N. K. Krishnan <hplabs!krishnan> writes:
> ...To change mode of the symbolic link
> one could use
>
> chmod(name,mode);
Unfortunately, changing the mode of a symbolic link doesn't keep other people
from using it. In this demo, "bar" is a symbolic link with no permissions...
note that you can still access "foo":
$ ls -l bar foo
l--------- 1 jerryp 3 Aug 12 07:08 bar -> foo
-rw-r--r-- 1 jerryp 13 Aug 12 07:07 foo
$ cat foo
This is foo.
$ cat bar
This is foo.
That's too bad. I'd like to be able to deny read permission on links
to keep object code from being read accidentally. That'd be useful in,
say, a "bin" directory that has both shell scripts and object code:
$ ls -l prog obj/prog
l--x--x--x 1 jerryp 9 Aug 12 07:09 prog -> objs/prog
-rwxr-xr-x 1 jerryp 13312 Jul 22 07:38 objs/prog
$ grep /bin/vi *
editfile: /bin/vi $arg
prog: Permission denied
reportmk: /bin/vi $*
Of course, denying read permission on just the link wouldn't stop someone from
copying the file at the end of the link if *it* had read permission. But
does anyone know why the mode of symbolic links is ignored (for speed, maybe)?
--
Jerry Peek, UNIX Training Instructor, Tektronix, Inc. 503/627-1603
MS 74-222, P.O. Box 500, Beaverton, OR 97077
{allegra,decvax,hplabs,ihnp4,ucbvax}!tektronix!tektools!jerryp
jerryp%tektools@tektronix.csnet
------------------------------
Date: Thu, 8 Aug 85 14:01:50 edt
From: Chris Torek <chris@maryland.ARPA>
Subject: [f]chmod on 4.2BSD
Seems to me that having fchmod and chmod both follow symbolic links is
more consistent. In any case, the mode information in a symbolic link
is totally ignored by the kernel, so you never need to change it anyway.
------------------------------
Date: 14 Aug 1985 2203-EDT (Wednesday)
From: vax135!petsd!joe (Joe Orost)
Subject: Data compression program available
Version 4.0 of "compress", the Lempel-Ziv data compression program for any
un*x-like system has been posted to "mod.sources". It has been BETA tested
on over 10 different systems. It will be distributed with BSD 4.3 and
netnews 2.10.3. Make sure somebody installs compress on your system.
Here is the README file:
------------------------------------------------------------
[Ed note: I have excised the README file because I have seen it
posted to at least one other newsgroup. Let's just say that this
version of compress seems to have a lot going for it and looks like
it is well worth checking out. RWH.]
--
Joseph M. Orost, ihnp4!vax135!petsd!joe, vax135!petsd!joe@BERKELEY
(201) 758-7284
MS 313; Perkin-Elmer; 106 Apple St; Tinton Falls, NJ 07724
------------------------------
Date: 11 Aug 85 21:38:30 CDT (Sun)
From: ihnp4!ho95e!wcs
Subject: Digest V2 #14: Disk Quotas
What we've found most effective is an auto-archive mechanism.
Obviously it won't work in a university enviroment, where disk space
and most computer accounting works on a semester basis, but for longer
time cyles it's great. For each file with access-time > N months
(usually 3 or 6), the file disappears off the disk and is eaten by the
IBM machine in the basement. I assume it go off to tape, or to the
infinitely large Mass Storage System, or whatever, but you can
theoretically get it back if you want it. When files get archived,
their owners receive both electronic and paper mail.
------------------------------
Date: Sun, 11 Aug 85 10:24:13 edt
From: allegra!phri!roy (Roy Smith)
Subject: file attributes (actually magic numbers)
In an article posted to net.unix, Tom Roberts <ihnp4!ihnet!tjr> says:
> I can see no compelling reason not to put such simple attributes into
> a header at the top of the file, probably starting with a new magic number.
Ignoring the issue of file attributes for the moment, it seems
that if people are going to keep making up magic numbers for different
kinds of files, there should be some sort of central registry to avoid
duplication (like Xerox does for Ethernet addresses). Does such a registry
exist?
Just how does one go about picking magic numbers anyway? Are any
"better" than others? Do you just pick a random 32-bit integer with bits
7, 15, 23, and 31 set so it can't be confused with any ascii characters?
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?
Roy Smith <allegra!phri!roy>
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016
------------------------------
Date: 9 Aug 85 13:02:42 CDT (Fri)
From: busch!dpg
Subject: lock file alternative
On several occaissions I've found it useful to make sure that only one copy of
a program is running. If another copy starts up, I want it to check that the
first copy is running and then die. 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. 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.]
We have come up with a better method using ETEXTBSY. The program tries to
access(2) "itself" (i.e. the executable file) with write permission. If the
access fails with errno=ETXTBSY then a previous copy must already be running.
This phenomenon relies on an undocumented feature of both access(2) and open(2)
that ETXTBSY is checked before EPERM. It works in SVR2 and BSD 4.1; are there
any UNIX versions where this doesn't work?
[Ed note: If it isn't in the System V Interface Definition,
then it isn't guaranteed to continue that way in Standard
System V. Just be aware of the potential for future
problems if you deviate from published interfaces. RWH.]
Here's some code:
main(argc, argv)
int argc;
char **argv;
{
...
if (isbusy(argv[0]))
exit(EX_BUSY);
...
}
#include <errno.h>
int
isbusy(arg0)
char *arg0;
{
extern int errno;
char *fullpath;
/*
* Get full path from argv[0].
* If first char is '/', then we already have full path.
* Otherwise, must parse $PATH and check each component.
* This is not foolproof, since exec(2) lets you put anything
* in argv[0].
*/
fullname = getfull(argv[0]);
/*
* Check access for text busy
*/
if (access(fullname, 2))
if (errno == ETXTBSY)
return(1);
return(0);
}
--
David Grossman ..!ihnp4!we53!busch!dpg
Anheuser-Busch Companies 314/577-3125
One Busch Place, Bldg. 202-4, St. Louis, MO 63118
------------------------------
Date: Wed, 14 Aug 85 09:16:48 -0200
From: ihnp4!seismo!mcvax!philmds!duvel!sater
Subject: Question about initial ttyline states at first open
I recently got bitten by the fact that terminal lines at first open
hace the ECHO bit set. This caused considerable character bouncing
from my machine to an X25 pad that shouted a message to the host,
which echoed it, this was received as a command, an errormessage
came back etc...
I have looked at kernel code for a couple of systems, it seems that
at least V7 and 4.[12] BSD have it organized this way.
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.
If neither one of you have a clue I might send the question to
Dennis Ritchie, because that piece of code probably was written by him.
Hans van Staveren, Philips Micro Development Systems
..!{seismo|philabs|decvax}!mcvax!philmds!sater
In the distant future: Hans.van.Staveren@mds.philips.nl.eur.UUCP
------------------------------
Date: 15 Aug 85 13:56:10 PDT (Thu)
From: <hplabs!hp-pcd!orstcs!hakanson@orstcs>
Subject: rwhod doesn't
I suppose we've missed something obvious, but we've looked
everywhere we can think of, with no success. We just brought
up our second VAX-11/750 running a clone of our first VAX's
4.2bsd system. The two machines each have their own ethernet
address (via Interlan boards), unique hostnames, and unique
gateway names (I think that's what you call them -- the names
you give to "ifconfig" at boot time).
The problem is that the rwho daemons don't seem to be talking
to each other. We can telnet, ftp, talk, rcp, rlogin/rsh/rexec,
and sendmail (smtp) between the two machines, but no rwho information
is being collected on either host. Perhaps someone will be able
to point out a bug fix or a configuration detail we've missed....
Marion Hakanson CSnet: hakanson%oregon-state@csnet-relay
UUCP : {hp-pcd,tektronix}!orstcs!hakanson
------------------------------
Date: Sat, 17 Aug 85 18:05:54 edt
From: allegra!phri!roy (Roy Smith)
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>
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016
------------------------------
End of Unix Technical Digest
******************************
--
Ronald W. Heiby / netnews@wnuxb.UUCP
AT&T Information Systems, Inc., Lisle, IL (CU-D21)