UNIX-WIZARDS Digest V1#111
Mike Muuss
Unix-Wizards-Request at BRL.ARPA
Tue Jul 23 02:33:00 AEST 1985
UNIX-WIZARDS Digest Sat, 20 Jul 1985 V1#111
Today's Topics:
pcc for 8088
re: Dump(8) and the Modified Tower of Hanoi
Help on sed script for px src
mailwatch script wanted
Re: instability in Berkeley versus AT&T releases
Re: monitoring ttys
RM05 and TE16 on the same controller
AT&T Long Distance
Re: inode number -> pathname? (4.2BSD)
Alternate object code linker being sought
Re: instability in Berkeley versus AT&T releases
Re: mailwatch script wanted
Xenix Crash? Trivial...
Re: inode number -> pathname? (4.2BSD)
Killing processes that are sleeping with -ve priority
Re: shorts vs. ints on a VAX 11/750
Re: inode number -> pathname? (4.2BSD)
Re: History lessons
Re: Speeding up the 3B2...
-----------------------------------------------------------------
From: ddl at harvard.ARPA (Dan Lanciani)
Subject: pcc for 8088
Date: 19 Jul 85 05:08:12 GMT
To: unix-wizards at brl-tgr.arpa
Has anyone had any luck getting the pcc to generate 8088 code?
Dan Lanciani
ddl at harvard
-----------------------------
From: rfb at cmu-cs-h.ARPA (Rick Busdiecker)
Subject: re: Dump(8) and the Modified Tower of Hanoi
Date: 19 Jul 85 13:09:23 GMT
To: unix-wizards at brl-tgr.arpa
As to how the sequence:
0 3 2 5 4 7 6 9 8
relates to the Tower of Hanoi algorithm, I'm not completely sure however I can
generate the sequence:
1 3 2 0 5 4 7 6 9 8...
I believe dump(8) refers to a modified version of the sequence.
Number discs starting with 0 on the top. The post numbered 0, 1, 2. Consider
the sequence moves as ordered pairs (stone, post). If you add these numbers
and then take the first occurrance of any given number, you get the above
sequence.
1 3 2 0 5 4
(0,1) (1,2) (0,2) (2,1) (0,0) (1,1) (0,1) (3,2) (0,2) (1,0) (0,0) (2,2) (0,1)
(1,2) (0,2) (4,1) (0,0) (1,1) (0,1) (2,0) (0,2) (1,0) (0,0) (3,1) (0,1) (1,2)
7
(0,2) (2,1) (0,0) (1,1) (0,1) (5,2) (0,2) (1,0) (0,0) (2,2) (0,1) (1,2) (0,2)
6
(3,0) (0,0) (1,1) (0,1) (2,0) (0,2) (1,0) (0,0) (4,2) ...
As for an inventor, the story I've always heard is that there is a 64-disk
Tower that is being moved by Bhuddist Monks, and that when they complete their
task (they believe) the world will come to an end. However, if they move a
disk per second it will take 2^64 (~ 1.84 x 10^19) seconds to complete. This
is about 584 billion years, so it shouldn't affect people reading the bboard
very much!
Rick Busdiecker
rfb at cmu-cs-h.arpa
-----------------------------
From: kfall at trwrba.UUCP (Kevin Fall)
Subject: Help on sed script for px src
Date: 16 Jul 85 17:34:52 GMT
To: unix-wizards at brl-tgr.arpa
In the Berkeley source for px, the pascal executor,
there is a set of scripts for sed which change
some of the assembly language source, depending
on the target machine (eg. mc68000.sed, vax.sed).
Can someone provide me more info about these?
and/or
Does anyone have the necessary script for a Perkin-Elmer?
- Kevin
--
Kevin R. Fall
TRW Electronics and Defense Sector
University of California, Berkeley
UUCP: {decvax,randvax,ucivax,ucbvax,hplabs,ihnp4}!trwrb!trwrba!kfall
ARPA: trwrba!kfall at aero.ARPA or kfall%ucbcory at ucb-vax.BERKELEY.EDU
AT&T: (213) 535-6050
-----------------------------
From: wa371 at sdcc12.UUCP (Senior Gnome)
Subject: mailwatch script wanted
Date: 16 Jul 85 06:10:05 GMT
To: unix-wizards at brl-tgr.arpa
Does anyone have a suggestion for a shell script for my .login
file, which will announce immediately upon login whether I have mail
or not, without putting me into the mail program if I don't want
to be.
It should run under the 4.2 c-shell.
Thanks.
Cheers,
Bernd <bear-nd> *** hooray for USENET ***
UUCP: ...!ucbvax!sdcsvax!sdcc12!wa371, ARPA: sdcsvax!sdcc12!wa371 at nosc
-----------------------------
From: hammond at petrus.UUCP (Rich A. Hammond)
Subject: Re: instability in Berkeley versus AT&T releases
Date: 17 Jul 85 12:07:47 GMT
To: unix-wizards at brl-tgr.arpa
> By implication that puts all commercial vendors of 4.2BSD systems
> in the "unstable computing environment business"?
Judging by how often we find bugs and our machines crash, I'd say yes,
runnning 4.2 BSD is being in an unstable computing environment.
-----------------------------
From: heiby at cuae2.UUCP (Ron Heiby)
Subject: Re: instability in Berkeley versus AT&T releases
Date: 17 Jul 85 15:51:21 GMT
To: unix-wizards at brl-tgr.arpa
In article <2423 at sun.uucp> gnu at sun.uucp (John Gilmore) writes:
>By implication that puts all commercial vendors of 4.2BSD systems
>in the "unstable computing environment business"?
There there, John. I was talking about the University of CA at Berkeley.
I was not talking about any commercial vendors. I have no knowledge of
Sun's quality control, although I have heard good reports from users
of Sun systems. BTW, in my previous job, I used a commercial port of
System III to a M68000 based system. The quality on that product was
marginal. So, I know enough not to be talking about quality of commercial
products based only on their porting base (although I have my favorite).
My remarks dealt only with the orientation of the organization that puts
out System V versus the organization that puts out BSD. Both are available.
It is up to the organization that purchases either to understand the
pros and cons involved. I'm sorry my remarks could have been mis-interpreted.
--
Ron Heiby heiby at cuae2.UUCP (via ihnp4)
AT&T-IS, /app/eng, Lisle, IL (312) 810-6109
-----------------------------
From: elman at sdcsvax.UUCP (Jeff Elman)
Subject: Re: monitoring ttys
Date: 17 Jul 85 04:43:27 GMT
To: unix-wizards at brl-tgr.arpa
> Problem: Users frequently have problems with various application
> programs, and in order to help them I have to go find them, look
> over their shoulder while they reproduce the problem.
>
> Is there anyway I can monitor their i/o from the console
> terminal, like on CMS (IBM) systems? (The system administrator can
> watch a user "conversation" with CMS.)
>
I have added some code to our tty handler to do this. It allows
a tty to either share or take over the i/o to/from another tty.
It's a bit of a pain. In addition to the changes to the tty handler
it involves changing the tty structure, adding a new system call &
entry point, plus the libc.a assist. I can (relucntantly) supply messy
details if anyone is interested.
By the way, this is under 4.2BSD.
Jeff Elman
Phonetics Lab, UC San Diego
ARPAnet: elman at ucsd
UUCP: ucbvax!sdcsvax!sdamos!elman
-----------------------------
From: gattesch at i2unix.UUCP (Alessandro Gatteschi)
Subject: RM05 and TE16 on the same controller
Date: 17 Jul 85 09:12:17 GMT
To: unix-wizards at brl-tgr.arpa
I was told by DEC people that VMS is able to manage VAX configurations
with RM05 and TE16 on the same controller. It seems very strange to
me, but anyway, this configuration should be managed even by UNIX
4.2bsd.
Does anyone in Unix-land have any idea or experience about disks and
tapes on the same controller ??
Thanks
Alessandro Gatteschi
Systems & Management
Piazza Solferino 7
10121 Torino - Italy
.....!mcvax!i2unix!gattesch
-----------------------------
From: mcvoy at uwvax.UUCP (Larry Mcvoy)
Subject: AT&T Long Distance
Date: 19 Jul 85 18:18:59 GMT
To: unix-wizards at brl-tgr.arpa
*** REPLACE THIS LINE WITH YOUR MIND ***
Does anyone know if Bell Labs still gets money from AT&T's long distance
profits? If not, where are they getting their money? Government contracts?
Respond to: arpa: mcvoy at wisc-rsch.arpa
uucp: {inhp4, seismo}!uwvax!geowhiz!geophiz!lwm
-----------------------------
From: ed at mtxinu.UUCP (Ed Gould)
Subject: Re: inode number -> pathname? (4.2BSD)
Date: 16 Jul 85 17:12:34 GMT
To: unix-wizards at brl-tgr.arpa
In article <11465 at brl-tgr.ARPA> phil at RICE.ARPA (William LeFebvre) writes:
> ... If it were possible to set the current working directory
>to a given inode and device... All
>the permission information, and even the bit denoting whether or not
>this inode refers to a directory is stored in the inode, and can easily
>be checked in such a call. Putting such a call in would be easy. Just
>do what "chdir" (well, actually "chdirec" in 4.2) does after it calls
>"nami". Why is this hard?
It's not hard, but it violates the protection model of the Unix
filesystem. Unix protection is based not only on the permissions of a
file itself, but on the permissions of *all* of the directories in the
path leading to the file. Consider the following:
drwx------ 3 ed mtxinu 512 Jul 16 09:58 a
drwxr-x--- 3 ed mtxinu 512 Jul 16 09:58 a/b
drwxr-xr-x 2 ed mtxinu 24 Jul 16 09:58 a/b/c
Directory a/b/c has read and execute permissions for everyone, so it
might seem that anyone could access the files in it. In fact, only
"ed" can access it because of the permissions on directory a. (Of
course, there are ways that ed or the super-user could *allow* others
to access a/b/c - even with the permissions as they are shown - but
that's not the point here.)
>Now, what would be hard would be generating the full path name for an
>arbitrary file given just the inode and device. The only program that
>can do that is find, and I strongly suspect that that will never change
>in the near or far future. Doing so would violate one of the founding
>principles of the Unix file system. But with a directory, you know
>that (save symbolic links) there is one unique path name for that
>directory.
Founding principles? I don't think so. If I remember correctly, the
first Unix allowed multiple, arbitrary links to directories. Since the
filesystem was essentially constructed by hand, this wasn't a real
problem. Only after more facilities were added to the system to
manipulate the filesystem, and checking programs like icheck and dcheck
were written, was the "strict tree" restriction added.
The ncheck program is the fastest way to do the inode-to-name search,
although the solutions using find will work, too. Ncheck is faster
because it reads the disk and decodes the filesystem itself, rather
than using the kernel to do the work. It must have permission - usually
granted only to the super-user - to do this, however.
--
Ed Gould mt Xinu, 2910 Seventh St., Berkeley, CA 94710 USA
{ucbvax,decvax}!mtxinu!ed +1 415 644 0146
"A man of quality is not threatened by a woman of equality."
-----------------------------
From: larryv at wlcrjs.UUCP (Larry W. Virden)
Subject: Alternate object code linker being sought
Date: 17 Jul 85 13:55:32 GMT
Keywords: loader, link edit,
To: unix-wizards at brl-tgr.arpa
I am in search of information on a public domain link-edit
program. The features which I need involve the ability to specify either
a series of alternate directories to search, or even better, a multiple
pass link-editor. The results would be less restriction on composition of
archive object libraries and less worry about the ordering between
libraries. Any info that can be provided will be appreciated.
--
Larry W. Virden
A user of the Free Access chinet board...
...!wlcrjs!larryv
-----------------------------
From: davest at daemon.UUCP (Dave Stewart)
Subject: Re: instability in Berkeley versus AT&T releases
Date: 18 Jul 85 16:27:34 GMT
To: unix-wizards at brl-tgr.arpa
In article <2423 at sun.uucp> gnu at sun.uucp (John Gilmore) writes:
>> ... We do a good job by making darn sure
>> that what we do doesn't break something (like a shell script or worse) and
>> that we spend our efforts spending resources on the most important/needed
>> enhancements first.
>
>By implication that puts all commercial vendors of 4.2BSD systems
>in the "unstable computing environment business"?
There are also plenty of examples where AT&T adds a BSD feature,
but changes the command or system call name or syntax. Isn't that
referred to as the NIH (Not Invented Here) syndrome? When will AT&T
(and DEC for that matter) realize that UC Berkeley is NOT a competitor?
Stepping down from his soapbox ...
--
David C. Stewart uucp: tektronix!davest
Small Systems Support Group csnet: davest at TEKTRONIX
Tektronix, Inc. phone: (503) 627-5418
-----------------------------
From: ajd at yodel.UUCP (Andrew J. Davis)
Subject: Re: mailwatch script wanted
Date: 19 Jul 85 12:50:24 GMT
To: unix-wizards at brl-tgr.arpa
Under 4.2 flavored systems, the command "biff y", set .login will notify
you if new mail arrives and who it is from. I believe this is what you
want. Is this satisfactory?
The command "biff n" disables new mail notification.
Andrew J. Davis
(617)-467-8366
DTN: 262-8366
U.S. Mail: Digital Equipment Corporation
Internal Software Services
Systems and Network Support
IND-3/C10
67 Forest Street
Marlboro, Mass. 01752
UUCP: decvax!yodel!ajd
ENET: decwrl::rhea::yodel::ajd
"Gentlemen, surely you're not going to take the word of a souless mechanical
device over that of a real flesh and blood man."
-----------------------------
From: ignatz at aicchi.UUCP (Ihnat)
Subject: Xenix Crash? Trivial...
Date: 18 Jul 85 03:37:52 GMT
To: unix-wizards at brl-tgr.arpa
Gosh, you have to go into a program? I just discovered tonight, while
'adb'ing a stripped object (DON'T ask why I would want to do it--object
licensees have to do many things a respectable source licensee wouldn't
*dream* of), that I can trash the kernel by simply trying to single-step
through a system call!
I'm running Xenix 3.0b on an Altos 586. I'm curious if this will happen
on an AT or XT, but please...backup and 'sync' your disks if you're willing
to attempt to make this sacrifice for the expansion of humankind's knowledge.
If you've an Altos running Xenix? I dunno...maybe make 'adb' executable
only by root? (heh, heh...)
Dave "Damn, am I glad my 80-meg didn't get trashed" Ihnat
Analysts International Corp.
ihnp4!aicchi!ignatz
ihnp4!aicchi!homebru!ignatz
--
Dave Ihnat
Analysts International Corporation
(312) 882-4673
ihnp4!aicchi!ignatz
-----------------------------
From: henry at utzoo.UUCP (Henry Spencer)
Subject: Re: inode number -> pathname? (4.2BSD)
Date: 12 Jul 85 17:09:19 GMT
To: unix-wizards at brl-tgr.arpa
> ... If it were possible to set the current working directory
> to a given inode and device, then pwd would give you the answer. All
> the permission information, and even the bit denoting whether or not
> this inode refers to a directory is stored in the inode, and can easily
> be checked in such a call...
This proposal has the side effect of making a significant change to the
semantics of Unix file protection. The permission bits on a Unix
directory are *not* sufficient for permission checking, because the
permissions of the directories above it in the tree also matter. It
can be done the other way, where parent permissions don't matter --
I think Multics did it that way -- but this would require changes to
both programs (notably mkdir, which would have to tighten up directory
permissions) and user habits (making your home directory private no
longer suffices to make everything under it private).
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry
-----------------------------
From: ron at oscvax.UUCP (Ron Janzen)
Subject: Killing processes that are sleeping with -ve priority
Date: 12 Jul 85 19:46:01 GMT
To: unix-wizards at brl-tgr.arpa
Occasionally I will run into a process that is sleeping with
a negative priority. It is immune to all forms of kill.
These processes usually occur in conjunction with the tape drive
but they have happened with ttys and a frame buffer that
we have on our system. When this happens it hangs up the respective
device. In the past I have always had to reboot the system to
unhang the device. I have also tried turning the power off to the
device in the hopes that this would kick the driver awake. I
was wondering if there is some magic (poke some magic address
in /dev/kmem, etc) I can do to tell the driver to stop being
a pain in the $%#. I am running on a VAX 750 under bsd4.1 (no source)
with a TS-11 tape drive. When I do a ps on the offending process
it tells me it is at PRI -5 and the wait channel (WCHAN) points
to a thing called _ctsbuf.
Well I have to go and reboot the system :-).
Thanks in advance for any help.
--
Ron Janzen
Ontario Science Centre, Toronto
...!{allegra,ihnp4,linus,decvax}!utzoo!oscvax!ron
-----------------------------
From: chris at umcp-cs.UUCP (Chris Torek)
Subject: Re: shorts vs. ints on a VAX 11/750
Date: 20 Jul 85 02:47:30 GMT
To: unix-wizards at brl-tgr.arpa
>Well, there isn't any extra overhead with fetching a long as opposed to a
>short -- the fetch is always 32 bits.
On a 780, the fetch is actually 64 bits (at least memory->cache---how
wide is the cache->CPU path?).
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251)
UUCP: seismo!umcp-cs!chris
CSNet: chris at umcp-cs ARPA: chris at maryland
-----------------------------
From: tim at cithep.UucP (Tim Smith )
Subject: Re: inode number -> pathname? (4.2BSD)
Date: 18 Jul 85 03:43:05 GMT
To: unix-wizards at brl-tgr.arpa
find /file_system will search the specified file system AND all file
systems that are mounted on a directory within the specified file system.
On my systems, I run ncheck out of crontab once a night on all filesystems.
--
Tim Smith
ihnp4!{wlbr!callan,cithep}!tim
-----------------------------
From: tim at cithep.UucP (Tim Smith )
Subject: Re: History lessons
Date: 18 Jul 85 03:55:17 GMT
To: unix-wizards at brl-tgr.arpa
> I have it from a reliable source (Ritchie) that in the original Unix file
> system, the directory structure was an arbitrary graph. It was changed
> to a tree because of the hair involved in consistency checking. As late
> as v6, ln command allowed root to link directories, and across file
> systems. This may have been a Purdue hack, though.
Root can still link directories, as far as the kernel is concerned. As for
linking across file systems, this must be a Purdue hack, since it is not
possible on ordinary v6,v7,TS 1.?, SIII, and SV for very fundamental reasons.
How did they change the file system to allow this?
--
Tim Smith
ihnp4!{wlbr!callan,cithep}!tim
-----------------------------
From: gas at busch.UUCP (Glen Smith)
Subject: Re: Speeding up the 3B2...
Date: 18 Jul 85 12:07:43 GMT
To: unix-wizards at brl-tgr.arpa
I read with interest the article about the COBOL problems on the 3b2.
Based on the testing we did here, I think that the real problem lies in the
fact that all the COBOL's available on the 3B series are interpretive; at
least it was when we were looking for COBOL compilers. These compilers
actually take the source and generate some intermediate code that is then
interpreted by a resident runtime system.
On the other hand, there are some very good COBOL compilers available for the
IBM PC. I assume the same quality is also available for the AT series.
Glen Smith ..!ihnp4!we53!busch!abstl!gas
Anheuser-Busch Companies 314/577-2686
One Busch Place, Bldg. 202-7
St. Louis, MO 63118
-----------------------------
End of UNIX-WIZARDS Digest
**************************
More information about the Comp.unix.wizards
mailing list