Unix-Wizards-Request@BRL.ARPA (Mike Muuss) (07/22/85)
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@harvard.ARPA (Dan Lanciani) Subject: pcc for 8088 Date: 19 Jul 85 05:08:12 GMT To: unix-wizards@brl-tgr.arpa Has anyone had any luck getting the pcc to generate 8088 code? Dan Lanciani ddl@harvard ----------------------------- From: rfb@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@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@cmu-cs-h.arpa ----------------------------- From: kfall@trwrba.UUCP (Kevin Fall) Subject: Help on sed script for px src Date: 16 Jul 85 17:34:52 GMT To: unix-wizards@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@aero.ARPA or kfall%ucbcory@ucb-vax.BERKELEY.EDU AT&T: (213) 535-6050 ----------------------------- From: wa371@sdcc12.UUCP (Senior Gnome) Subject: mailwatch script wanted Date: 16 Jul 85 06:10:05 GMT To: unix-wizards@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@nosc ----------------------------- From: hammond@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@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@cuae2.UUCP (Ron Heiby) Subject: Re: instability in Berkeley versus AT&T releases Date: 17 Jul 85 15:51:21 GMT To: unix-wizards@brl-tgr.arpa In article <2423@sun.uucp> gnu@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@cuae2.UUCP (via ihnp4) AT&T-IS, /app/eng, Lisle, IL (312) 810-6109 ----------------------------- From: elman@sdcsvax.UUCP (Jeff Elman) Subject: Re: monitoring ttys Date: 17 Jul 85 04:43:27 GMT To: unix-wizards@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@ucsd UUCP: ucbvax!sdcsvax!sdamos!elman ----------------------------- From: gattesch@i2unix.UUCP (Alessandro Gatteschi) Subject: RM05 and TE16 on the same controller Date: 17 Jul 85 09:12:17 GMT To: unix-wizards@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@uwvax.UUCP (Larry Mcvoy) Subject: AT&T Long Distance Date: 19 Jul 85 18:18:59 GMT To: unix-wizards@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@wisc-rsch.arpa uucp: {inhp4, seismo}!uwvax!geowhiz!geophiz!lwm ----------------------------- From: ed@mtxinu.UUCP (Ed Gould) Subject: Re: inode number -> pathname? (4.2BSD) Date: 16 Jul 85 17:12:34 GMT To: unix-wizards@brl-tgr.arpa In article <11465@brl-tgr.ARPA> phil@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@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@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@daemon.UUCP (Dave Stewart) Subject: Re: instability in Berkeley versus AT&T releases Date: 18 Jul 85 16:27:34 GMT To: unix-wizards@brl-tgr.arpa In article <2423@sun.uucp> gnu@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@TEKTRONIX Tektronix, Inc. phone: (503) 627-5418 ----------------------------- From: ajd@yodel.UUCP (Andrew J. Davis) Subject: Re: mailwatch script wanted Date: 19 Jul 85 12:50:24 GMT To: unix-wizards@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@aicchi.UUCP (Ihnat) Subject: Xenix Crash? Trivial... Date: 18 Jul 85 03:37:52 GMT To: unix-wizards@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@utzoo.UUCP (Henry Spencer) Subject: Re: inode number -> pathname? (4.2BSD) Date: 12 Jul 85 17:09:19 GMT To: unix-wizards@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@oscvax.UUCP (Ron Janzen) Subject: Killing processes that are sleeping with -ve priority Date: 12 Jul 85 19:46:01 GMT To: unix-wizards@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@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@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@umcp-cs ARPA: chris@maryland ----------------------------- From: tim@cithep.UucP (Tim Smith ) Subject: Re: inode number -> pathname? (4.2BSD) Date: 18 Jul 85 03:43:05 GMT To: unix-wizards@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@cithep.UucP (Tim Smith ) Subject: Re: History lessons Date: 18 Jul 85 03:55:17 GMT To: unix-wizards@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@busch.UUCP (Glen Smith) Subject: Re: Speeding up the 3B2... Date: 18 Jul 85 12:07:43 GMT To: unix-wizards@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 **************************