Path: utzoo!utgpu!watmath!clyde!att!rutgers!mailrus!ames!haven!adm!xadmx!postmaster@nusc.arpa From: postmaster@nusc.arpa (SMTP MAILER) Newsgroups: comp.unix.questions Subject: Mail not delivered yet, still trying Message-ID: <17690@adm.BRL.MIL> Date: 2 Dec 88 18:52:35 GMT Sender: news@adm.BRL.MIL Lines: 1128 ----Mail status follows---- Have been unable to send your mail to, will keep trying for a total of three days. At that time your mail will be returned. ----Transcript of message follows---- Date: 1 Dec 88 08:10:00 EST From: Subject: INFO-UNIX Digest V6#031 To: "baynes" Received: from SEM.BRL.MIL by nusc.arpa with SMTP ; Thu, 1 Dec 88 08:09:16 EST Received: from SEM.BRL.MIL by SEM.brl.MIL id ab04903; 1 Dec 88 3:26 EST Received: from sem.brl.mil by SEM.BRL.MIL id aa04894; 1 Dec 88 2:46 EST Date: Thu, 01 Dec 88 02:46:12 EST From: The Moderator (Mike Muuss) To: INFO-UNIX@BRL.MIL Reply-To: INFO-UNIX@BRL.MIL Subject: INFO-UNIX Digest V6#031 Message-ID: <8812010246.aa04894@SEM.BRL.MIL> INFO-UNIX Digest Thu, 01 Dec 1988 V6#031 Today's Topics: Adventure shell Troff "grap" question Re: ls -l Re: * Question Re: Info needed on workstations Re: GCOS field System 5.3.1 signal() replacement? signals to running processes Re: How to mimic the terminal driver? Pre-formatted tapes for HP drives A UUCP question SVR3 Manuals Re: GCOS field Re: A UUCP question Re: * Question Re: How to mimic the terminal driver? Re: * Question Re: Adventure shell Re: GCOS field Re: Troff "grap" question Re: Anonymous ftp's Nroff/Troff Floating Displays Re: Pre-formatted tapes for HP drives Re: ls -l Re: * Question Re: ls -l Re: SCCS: how to handle multiple developers/streams Re: ls -l Re: fio library routines ----------------------------------------------------------------- From: Jon Joshua Subject: Adventure shell Date: 30 Nov 88 06:27:13 GMT Keywords: anyone got it? To: info-unix@sem.brl.mil I heard someone mention a shell called the adventure shell. This shell turned Unix into an adventure game where you could pick up files and drop them elsewhere etc... Does anyone have more info on this shell? Better yet, does anyone have a copy? JOn. -- _____________________________________________________________________________ |o| Jonathan Joshua jjoshua@topaz.rutgers.edu Why not... |o| |o| Nothing better to do |o| |o| Anything is possible, |o| \o| except for skiing through a revolving door. |o| \_ ____/ \ |o| \/ \ _______________________________ ______________________|o| \___ / \/ \/ ----------------------------- From: Erik Ekkel Subject: Troff "grap" question Date: 29 Nov 88 11:44:55 GMT To: info-unix@sem.brl.mil I want to use the troff "grap" preprocessor to plot a graph. The problem is that the input has as x-coordinate weeknumbers. So the range of the x-axis is e.g. 8801:8852, 8901:8952, .......... How can i tell "grap" that there is a gap in the x-axis; that week 8901 is the successor of week 8852 and NOT 8900 ! -- __ / Erik Ekkel, Philips PTDSN (+31 55 433301) /-- __ o / Domain: ekkel@idca.tds.philips.nl /___ _/ (_(_ /( Uucp : ...!mcvax!philapd!ekkel ----------------------------- From: James Logan III Subject: Re: ls -l Date: 30 Nov 88 04:01:12 GMT Keywords: ls To: info-unix@sem.brl.mil In article <838@nih-csl.UUCP> ted@nih-csl.UUCP (ted persky) writes: # # When a user enters the command "ls -l" on a directory, a slew of # information is given with such things as last-modified time, # number of links, owner, group, etc. Such data is usually stored # in the inode. My question is this: does the "ls" program need to # open each file, to look at its inode in order to display this # data to standard output? # No, the "inode" is stored in an "inode table" stored near the beginning of a disk partition. It is basically an array of structures containing the information supplied by the stat(2) call (links, mode, UID, GID, etc.) plus a block number map for the file. This block number map consists of 13 block numbers. The first 9 block numbers refer to the first 9 blocks of the file's data. The 10th block number, known as the "single indirect" is the block number of another block on the disk containing more of the file's block numbers. The 11th, known as the "double indirect" is the block number of a disk block containing a list of block numbers that refer to disk blocks that contain more of the file's block numbers. The 12th, know as the "triple indirect" is the block number of a disk block containing a list of block numbers that refer to disk blocks that contain block numbers of disk blocks containing more block numbers of the file's data. Confused? I thought so. Of course, short files would not require all of these block numbers, but the blocks are there if you ever need a large file. (Try a 4 gigabyte file to be exact...) Anyway, the simple answer to your question is: "Yes, Virginia, there IS a Santa Clause." No, Wait... um... oh yeah, the "ls" command simply calls the stat(2) system call for each file you specified and the stat(2) call reads the inode table entry associated with that filename. The "ls" command does NOT read a single byte of the file's data. -Jim -- Jim Logan logan@vsedev.vse.com (703) 892-0002 uucp: ..!uunet!vsedev!logan inet: logan%vsedev.vse.com@uunet.uu.net ----------------------------- From: James Logan III Subject: Re: * Question Date: 30 Nov 88 04:27:29 GMT To: info-unix@sem.brl.mil In article <17661@adm.BRL.MIL> wmartin@almsa-1.arpa (Will Martin -- AMXAL-RI) writes: #I have a query about filename generation/wildcard expansion. I have looked #in the man pages and in several UNIX books, and talked about this locally, #but haven't found an explanation. I've tested it on both Sys V (on a Sperry #Unisys) and 4.3 BSD (on a VAX 750). It seems to be a consistent difference #between sh and csh. # #Given the situation where you are trying to redirect output to a directory #in some path structure, where you do have write access, but want to save #time in typing: # #Say my login directory is /usr/wm. I also own a directory in another filesystem: #"/data/save-backups". I am sitting in /usr/wm and want to put some data into #that other directory, but want to avoid typing out "save-backups" all the time. #There is nothing else under /data that begins with "sa". # #So I do this: # #cat foo > /data/sa*/bar or cat foo >> /data/sa*/bar # #Under "sh", no matter whether or not "bar" exists in that destination #directory, this won't work. I get the response: # #sh: /data/sa*/bar: cannot create # #The shell will not expand that "*" to fill out the directory name. I have to #type out the full "/data/save-backups/bar" pathname to get it to work. # Every version of the Bourne shell that I have seen does not interpret the filename expansion characters after a redirection symbol. I believe this is to prevent cat foobar >/data/sa*/bar from expanding into cat foobar >/data/sally/bar /data/sandy/bar which would effectively be the same as cat foobar /data/sandy/bar >/data/sally/bar which was probably not intended. The Korn shell gets this right by expanding the wildcard only if one file matches. If more than one file matches, the wildcard is used literally. -Jim -- Jim Logan logan@vsedev.vse.com (703) 892-0002 uucp: ..!uunet!vsedev!logan inet: logan%vsedev.vse.com@uunet.uu.net ----------------------------- From: "G.Pavlov" Subject: Re: Info needed on workstations Date: 30 Nov 88 05:20:50 GMT Posted: Wed Nov 30 00:20:50 1988 To: info-unix@sem.brl.mil In article <6060017@hpcupt1.HP.COM>, markd@hpcupt1.HP.COM (Mark Diekhans) writes: > I am considering buying a Unix workstation in the less than $15K department. > So far, the Sun-3s and the IBM PC RT look likely contenders. Does anyone have > any input on these or other UNIX workstations, both hardware and the versions > of UNIX for each? Thanks, How about an HP 9000 Model 340 ? greg pavlov, fstrf, amherst, ny ----------------------------- From: Jean-Pierre Radley Subject: Re: GCOS field Date: 30 Nov 88 04:03:40 GMT To: info-unix@sem.brl.mil In article <1257@vsedev.VSE.COM> logan@vsedev.VSE.COM (James Logan III) writes: >Does anyone know what GCOS really stands for and where it came from? In my flavor of unix, that's described as the "Comment" field. In volume 1 of the Unix Programmer's Manual, the old green books, that field was listed as GCOS job number, box number, optional GCOS user-id and the manual page went on to state: The GCOS field is used only when communicating with that system, and in other installations can contain any desired information. Elsewhere in the old green books, I get the implicit, not explicit, information that GCOS referred to a typesetting system at Murray Hill at the time that Osanna & Co. were inventing troff. -- Jean-Pierre Radley Honi soit jpr@dasys1.UUCP New York, New York qui mal ...!hombre!jpradley!jpr CIS: 76120,1341 y pense ...!hombre!trigere!jpr ----------------------------- From: Timothy Reed Subject: System 5.3.1 signal() replacement? Date: 30 Nov 88 04:28:17 GMT To: info-unix@sem.brl.mil I don't have access to a 5.3.1 system, but I understand that signal() has been replaced by a new set of signal handlers. Could someone kindly mail me a man page (I think that the replacement is sigset()?) or a brief summary of snytax and usage (and signals!) - doing so will make my life much easier!!! Thanks! Timothy Reed -- NAME : Timothy Reed PHONE: 7188527454 UUCP : ..!cmcl2!phri!dasys1!treed || ..!uunet!dasys1!treed MAIL : 300 Union St^MBkyn, NY^M11231 ----------------------------- From: Jonathan Sweedler Subject: signals to running processes Date: 30 Nov 88 07:01:28 GMT To: info-unix@sem.brl.mil I have a program that takes a long time to finish running. From time to time (sometimes never, sometimes more frequently) I would like to find out the current status. The way I accomplish this is to send one of the user defined signals (SIGUSR1 - no. 30) to the process. The process has a signal handler that catches this signal and writes out the current state (number of loops done, how long it has been running, when it will finish, etc.). This all works fine but only I (the owner of the process) can send the signal. If my boss, for example, wants to look at the status of the process, he can't. My questions are these: 1) Is there any way for someone who is not the owner of a process to send the process a signal? 2) Or, is there another way for a random user to cause a program to asynchronously print out a status report (or perform some action) once it has started running? I know I can have the program print out a status report every x minutes/hours/loops/whatever, but I don't want this. I want the report to be printed out only when specified to do so. I could also probably (haven't done this yet) write a shell script that would send the signal and is setuid to me but then if different people run the program (other than me), there must be different shell scripts that are setuid to each person who might run the program. For example, if either user A or user B might run the program, but it is user C that wants the progress report, then there must be a shell script setuid'ed to A and one setuid'ed to B. Is there a cleaner approach? -- Jonathan Sweedler === National Semiconductor Israel UUCP: ...!{amdahl,hplabs,decwrl}!nsc!taux01!cjosta Domain: cjosta@taux01.nsc.com ----------------------------- From: The Demented Teddy Bear Subject: Re: How to mimic the terminal driver? Date: 30 Nov 88 10:47:39 GMT Sender: dieter@nmtsun.nmt.edu To: info-unix@sem.brl.mil In article <35@umvlsi.ECS.UMASS.EDU>, vishwana@umvlsi (Chidambaram Vishwanath) writes: > > I have taken upon myself the following task, viz.,: I want to add > an extra feature to the C-shell whereby I can recall earlier commands > by pressing an arrow-key. By far the easiest solution to this problem is to use "ile", which was posted to comp.unix.wizards on July 7, 1988 by bpendlet@esunix.uucp. (Bob Pendleton, message id 907@esunix.uucp, to be exact). It fits between the user and his program by grabbing a pty and looking at everything that goes by. There are three problems with this package that I'm aware of. 1) Your version of unix must understand the concept of pty. This seems to be fairly common these days, so it isn't too much of a problem. 2) It grabs a pty, but doesn't update /etc/utmp, which upsets "talk" and other programs that do a getlogin (). This is pretty easy to fix (I just finished doing that about 4 hours ago, you see). 3) To keep things from getting real confused, the tty never echoes (i.e., the child's end doesn't echo), but the pty does. Therefore, there's no way for ile to know that the child would like echoing turned off. Translation: passwords echo. I haven't figured out a nice way around this yet. 4) There's no clear concept of "current directory". Since this would require something of a Know-What-I-Mean function, there's not much that can be done about it. Some advantages: 1) Ile notices when the child puts the tty into raw mode, and gets out of the way. Things like Emacs still work. 2) You now have an Emacs-like user interface. Things like ^A, ^E, ^T ESC-u, etc, all work. You can change the default key bindings to whatever you prefer. Characters insert by default. 3) File name completion exists, but only on absolute paths (start with a / or ~). I haven't figured out how to get an escape through to the shell for its completion yet, assuming it's possible. 4) *All* line-oriented programs suddenly have history, with a nice line editing capability. Ile maintains its own history list (accessed via ^P and ^N by default), and doesn't distinguish between what subprocess is reading from the pty. It's real convenient being able to pop up the history list and grab the command line you typed at the wrong program and give it to the right program. You don't need one of those "...relentlessly interactive, icon-based, rodent-infested, dumb-user- friendly, smart-user-crippling systems..."[*] any more. I have the original message (as you probably guessed from the exactness in identification given at the top). The diffs for diddling utmp nicely (cleans up after itself and such) are fairly small, and on their way to the original author. Please note that I will not be at this email address after Dec 12, so either get any requests in to me quickly, or send a note off to Mr. Pendleton. [*] Thanks to Mike Van Pelt for that description. Dieter Muller -- Welcome to the island. You are number six. dieter%nmt@relay.cs.net dieter@jupiter.nmt.edu ----------------------------- From: Pierre Mathieu Subject: Pre-formatted tapes for HP drives Date: 28 Nov 88 18:35:45 GMT Sender: news@istsists.ca Keywords: tape drive To: info-unix@sem.brl.mil Here are a couple of questions about HP tape drives. We have an HP 9000 series 350 system running HP-UX 6.2 with an HP 9144A tape drive. Question 1) Is it possible to load tapes into this drive that are not pre-formatted and format them from HP-UX? I have tried to use (non-HP) unformatted tapes in this drive but it just went into spasms and locked up totally refusing to use these tapes (which are in every way identical to HP's except that they are not pre-formatted). Question 2) If it is not possible, then does anybody know if other companies than HP make these pre-formatted tapes? We found that at twice the price of the other tapes out there, HP prices were a little excessive. :-) Thanks in advance for any help, Pierre Mathieu mathieu@ists.yorku.ca Institute for Space and Terrestrial Science mathieu@yunexus.yorku.ca Center for Research in Exp. Space Science York University, Ontario, Canada. ----------------------------- From: Mario Dorion Subject: A UUCP question Date: 29 Nov 88 19:23:26 GMT Keywords: 'ALARM' messages To: info-unix@sem.brl.mil Hi! I've got a UUCP problem. There's a uucp link (through standard modems) between my site (X02) and site cmtl01. This link has been used for a few months now for E-mail and file transfering without any problems. For a few weeks, cmtl01 have been giving me a news feed. Since then our commu- nications have been failing with depressing regularity. A (very) good number of our sessions end with *alarms* messages. Since I really have no ideas of what these messages mean I really don't know where to look! Any suggestions??? Here's a few lines from the uucico log and the uucp log. I am using HDP's UUCP with a system V system. *************************** uucico log *************************************** pkgetpack: Connodata=1 rec h->cntl 37777777602 send 40 pkgetpack: Connodata=1 rec h->cntl 37777777612 alarm 1 alarm 2 send 40 alarm 3 send 40 alarm 4 send 40 alarm 5 send 40 alarm 6 send 40 alarm 7 send 40 alarm 8 send 40 alarm 9 send 40 alarm 10 send 40 alarm 11 send 40 tries = 10 send 10 send 10 r short 2 want 3 rcount = 0 xcount = 0 cntrl - -1 send OO 0,imsg >exit code -1 Conversation Complete: Status FAILED **************************** uucp log ************************************ TM_cnt: 1 tm_name: /usr/spool/uucp/cmtl01/TM.10495.000 uucp cmtl01 (11/29-13:10:36,10495,0) FAILED (LOGIN FAILED) uucp cmtl01 (11/29-13:11:29,10495,0) FAILED (LOGIN FAILED) uucp cmtl01 (11/29-13:12:22,10495,0) FAILED (LOGIN FAILED) uucp cmtl01 (11/29-13:12:57,10495,0) SUCCEEDED (call to cmtl01 ) uucp cmtl01 (11/29-13:12:59,10495,0) OK (startup) uucp cmtl01 (11/29-13:13:00,10495,0) REMOTE REQUESTED (cmtl01!D.cmtl07d72574 --> X02!D.cmtl07d72574 (news)) news cmtl01 (11/29-13:16:03,10495,1) IN SEND/SLAVE MODE (INPUT FAILURE) news cmtl01 (11/29-13:16:03,10495,1) FAILED (conversation complete) uucp cmtl01 (11/29-13:25:58,10557,0) FAILED (LOGIN FAILED) uucp cmtl01 (11/29-13:26:47,10557,0) CAUGHT (SIGNAL 15) -- Mario Dorion | E-mail: mdorion@X02.UUCP XIOS Systems | ...uunet!attcan!cmtl01!X02!mdorion Montreal, Canada | 1 (514) 744-3410 | No thanks, no penguin, I already got one! ----------------------------- From: John Gayman Subject: SVR3 Manuals Date: 30 Nov 88 03:38:15 GMT To: info-unix@sem.brl.mil I recall seeing an advertisement a few months back from an outfit like Sams, Hayden, etc. offering a set of manuals for SVR3 much like those that are out for SVR2. Would anyone have a telephone number and or title/ISDN numbers for these ? I beleive it was about 3-4 books. Thanks. John -- John Gayman, WA3WBU | UUCP: uunet!wa3wbu!john 1869 Valley Rd. | ARPA: john@wa3wbu.uu.net Marysville, PA 17053 | Packet: WA3WBU @ AK3P ----------------------------- From: pim@mrevox.uucp Subject: Re: GCOS field Date: 30 Nov 88 14:46:00 GMT Nf-ID: #R:dasys1:-799600:mrevox:4400001:000:351 Nf-From: mrevox!pim Nov 30 09:46:00 1988 To: info-unix@sem.brl.mil Someone just the other day saw the GCOS(GECOS) field being prompted for and remarked that he hadn't seen that name for a while. He said that it stood for: General Electric Computer Operating System or General Electric Comprehensive Operating System It seems far fetched, but interesting. Paul MacMurdo pim@mrevox.bellcore.com ...!bcr!mrevox!pim ----------------------------- From: pim@mrevox.uucp Subject: Re: A UUCP question Date: 30 Nov 88 14:53:00 GMT Nf-ID: #R:cmtl01:-13700:mrevox:4400002:000:271 Nf-From: mrevox!pim Nov 30 09:53:00 1988 To: info-unix@sem.brl.mil We used to have the same problem when passing through a DATAKIT node. The problem was resolved when XON was shut off the line set up for UUCP. Paul MacMurdo pim@mrevox.bellcore.com Bellcore ...!bcr!mrevox!pim MRE 1C-343 435 South Street Morristown NJ 07960-1961 ----------------------------- From: "Richard A. O'Keefe" Subject: Re: * Question Date: 30 Nov 88 11:17:51 GMT Sender: news@quintus.uucp To: info-unix@sem.brl.mil In article <17661@adm.BRL.MIL> wmartin@almsa-1.arpa (Will Martin -- AMXAL-RI) writes: >Under "csh", if "bar" doesn't exist, I get: "/data/sa*/bar: No match", >but, if "bar" DOES exist, and I do either: > >cat foo > /data/sa*/bar or cat foo >> /data/sa*/bar > >it will work OK! So "csh" expands the wildcard * correctly in this case. > >And, if "csh" lets this work >as shown, why does it NOT work when creating the file initially? When you give a wildcard pattern in Csh, there has to be at least one thing in the file system which matches the complete pattern. Suppose you have an empty directory /data/savewhatsit/ and no other directories matching /data/sa* . Where then is there anything that matches the **whole** pattern /data/sa*/bar ? If you just want to save yourself a lot of typing, use a shell variable: Csh: set sa=/data/sa* echo works first time >$sa/bar Sh: sa=`echo /data/sa*` echo works first time >$sa/bar Your message was /usr/spool/news/comp/unix/questions/7149 here. In the Bourne shell, I did $ NEWS=/usr/spool/news $ cd $NEWS/comp/unix $ echo que*/7149 $ echo $NEWS/co*/un*/que*/7149 and both echos worked. This was on a Sequent, and the test worked in both the "att" and the "ucb" universes. For some real fun, I went to my home directory and made a subdirectory zabbo containing a file fred. $ echo trouble >zab*/fred zab*/fred: cannot create $ x=zab*/fred $ echo $x zabbo/fred $ echo real trouble >$x zab*/fred: cannot create Let's get this last one out of the way first. $ echo "$x" zab*/fred We see from this that when a variable is assigned a value, that value is not wild-card expanded ("globbed"). But if you use the value of the variable later in a context where globbing is done, the value will be globbed then. That's why I wrote sa=`echo /data/sa*` above. What about ">zab*/fred"? Why didn't that work? Well, you have to read the Sh manual page with extreme attention to detail. Several sorts of "evaluation" happen to a command line. Command SUBSTITUTION `command` is called and the output substituted Parameter SUBSTITUTION $thingies are replaced by their values File Name GENERATION "globbing", "wild-cards". The manual page says clearly that this happens after command and parameter substitution and blank interpretation. Now when we come to input/output redirection, we are told about word >>word and so on that "SUBSTITUTION" happens to the word before it is used. That's *all* that happens; file name generation (globbing, wild-card processing) is not done, and blank interpretation is not done either. $ y="BIG trouble" $ echo $y >$y $ ls BIG trouble fred $ ls $y BIG not found trouble not found $ rm "$y" You can see why the Bourne shell works this way: before command and parameter substitution the "word" is *one* thing; blank interpretation and file name generation could turn it into more than one thing, and what would that mean? The C shell handles it differently: % set y="BIG trouble" % echo $y >$y $y: Ambiguous. As should be clear by now, assignment to keyword parameters is another context where substitution is done but file name generation is not. ----------------------------- From: Doug Gwyn Subject: Re: How to mimic the terminal driver? Date: 30 Nov 88 19:18:12 GMT To: info-unix@sem.brl.mil In article <35@umvlsi.ECS.UMASS.EDU> vishwana@umvlsi.ECS.UMASS.EDU (Chidambaram Vishwanath) writes: > I have taken upon myself the following task, viz.,: I want to add >an extra feature to the C-shell whereby I can recall earlier commands >by pressing an arrow-key. [etc.] Why reinvent the wheel? The so-called "Tenex Cshell" already has similar support built in. I think it may even have become the standard 4.3BSD Cshell. You can also get this in the Korn shell and the BRL Bourne shell. A terminal editing wrapper process was posted to one of the newsgroups only a few months ago, if you want to use the separate-process approach. ----------------------------- From: Doug Gwyn Subject: Re: * Question Date: 30 Nov 88 19:22:31 GMT To: info-unix@sem.brl.mil In article <17661@adm.BRL.MIL> wmartin@almsa-1.arpa (Will Martin -- AMXAL-RI) writes: >cat foo > /data/sa*/bar >What I don't understand is why the expansion doesn't work under "sh". It was a deliberate design decision. The target of > should be just one word, not the potential multiple words that wildcard expansion might produce. To avoid unpleasant surprises, "sh" doesn't expand wildcards in such contexts. However, note that you can save typing using the BRL Bourne shell by using the filename completion feature to automatically fill in the rest of a pathname segment once you've typed the unambiguous prefix for it. I actually prefer this approach anyway, since I get to see the full expansion before the command is executed. ----------------------------- From: Doug Gwyn Subject: Re: Adventure shell Date: 30 Nov 88 20:36:10 GMT To: info-unix@sem.brl.mil In article jjoshua@topaz.rutgers.edu (Jon Joshua) writes: > I heard someone mention a shell called the adventure shell. >This shell turned Unix into an adventure game where you could pick up >files and drop them elsewhere etc... Does anyone have more info on >this shell? Better yet, does anyone have a copy? I mailed you the one I devised a few years ago. Mine was inspired by somebody's joke, but it really does work and some people even claim to like it as a shell (they must be crazy). It's a huge Bourne shell script. The version I sent requires shell functions, which is an SVR2 or later feature. If you have an obsolete shell, you will need to change the use of those functions (which manipulate lists) to in-line shell code. There are also some definitions at the start of the file for paginators, etc. that you'll need to configure properly. I think my distribution kit includes source code for the "ask" utility which is used to get responses to yes/no questions. ----------------------------- From: Doug Gwyn Subject: Re: GCOS field Date: 30 Nov 88 20:41:13 GMT To: info-unix@sem.brl.mil In article <7996@dasys1.UUCP> jpr@dasys1.UUCP (Jean-Pierre Radley) writes: >In article <1257@vsedev.VSE.COM> logan@vsedev.VSE.COM (James Logan III) writes: >>Does anyone know what GCOS really stands for and where it came from? >In my flavor of unix, that's described as the "Comment" field. That's what it has evolved to, since most current UNIX systems don't spool printer output etc. to Honeywell (formerly GE) systems. ----------------------------- From: Ken Keirnan Subject: Re: Troff "grap" question Date: 30 Nov 88 16:35:01 GMT To: info-unix@sem.brl.mil In article <618@wc11.idca.tds.philips.nl> ekkel@idca.tds.PHILIPS.nl (Erik Ekkel) writes: >I want to use the troff "grap" preprocessor to plot a graph. The problem is >that the input has as x-coordinate weeknumbers. So the range of the >x-axis is e.g. 8801:8852, 8901:8952, .......... > >How can i tell "grap" that there is a gap in the x-axis; that week 8901 is the >successor of week 8852 and NOT 8900 ! If you know the number of points along the x-axis in advance, one way would be to specify the number of x-axis intervals with the "coord" keyword and then make the week numbers tick labels. For example if you have 52 points on the x-axis: coord x 0,52 ticks bot out at 1 "8801",2 "8802" ... or whatever interval you want between ticks. I know this is messy, but nothing else comes to mind. -- Ken Keirnan - Pacific Bell - {att,bellcore,sun,ames,pyramid}!pacbell!pbhyf!kjk San Ramon, California kjk@pbhyf.PacBell.COM ----------------------------- From: Steve DeJarnett Subject: Re: Anonymous ftp's Date: 30 Nov 88 06:51:59 GMT To: info-unix@sem.brl.mil In article <380001@hpcea.CE.HP.COM> twakeman@hpcea.CE.HP.COM (Teriann Wakeman) writes: >>Doug Comer has a good book out on the details of internetworking. >Ah... Got any more info about this book? ie. name, publishing date/house? >availablity? Availability: Now Title: Internetworking with TCP/IP -- Principles, Protocols, and Architecture Publisher: Prentice-Hall Publishing Date: 1988 Cost: Around $40 Good book. Explains the concepts well to those who are unfamiliar with TCP/IP, but doesn't insult your intelligence if you do know something about it. ------------------------------------------------------------------------------- | Steve DeJarnett | Smart Mailers -> steve@polyslo.CalPoly.EDU | | Computer Systems Lab | Dumb Mailers -> ..!ucbvax!voder!polyslo!steve | | Cal Poly State Univ. |------------------------------------------------| | San Luis Obispo, CA 93407 | BITNET = Because Idiots Type NETwork | ------------------------------------------------------------------------------- ----------------------------- From: Doug Toppin Subject: Nroff/Troff Floating Displays Date: 30 Nov 88 16:42:58 GMT Keywords: Nroff,Troff To: info-unix@sem.brl.mil We are using nroff and the mm macros to generate our documentation and often have to insert pages created by other means (diagrams, etc). We are using floating displays in the following fashion: .nr De 1 \" follow output of floating page with page eject .nr Df 2 \" output floating display at top of a new page .DF stuff .De This will cause the current page to fill and then the next page will be reserved and ejected. This works well but we have not been able to insert successive floating displays without getting text pages between them. If anyone knows what to do I would appreciate it if they sent me an example via mail at: uunet!melpar!toppin Thanks Doug Toppin ----------------------------- From: Mike Khaw Subject: Re: Pre-formatted tapes for HP drives Date: 30 Nov 88 18:17:22 GMT To: info-unix@sem.brl.mil <274@istsists.ca>, by mathieu@ists.yorku.ca (Pierre Mathieu): > Question 1) Is it possible to load tapes into this drive that > are not pre-formatted and format them from HP-UX? Not that I know of; in fact, if you write onto a pre-formatted tape from a non-HP drive (e.g., a Sun) you destroy the formatted track(s?) and can no longer use the tape in the HP drive. > Question 2) If it is not possible, then does anybody know if other > companies than HP make these pre-formatted tapes? We 3M makes them. They are DC600HC tapes. Mike Khaw -- internet: mkhaw@teknowledge.arpa uucp: {uunet|sun|ucbvax|decwrl|ames|hplabs}!mkhaw%teknowledge.arpa hardcopy: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303 ----------------------------- From: Guy Harris Subject: Re: ls -l Date: 30 Nov 88 18:49:25 GMT Keywords: ls To: info-unix@sem.brl.mil >When a user enters the command "ls -l" on a directory, a slew of information >is given with such things as last-modified time, number of links, owner, group, >etc. Such data is usually stored in the inode. My question is this: does the >"ls" program need to open each file, to look at its inode in order to display >this data to standard output? No, it doesn't have to open the file; it can list the information about files you're not allowed to open. It uses the "stat" (or "lstat", on systems that have symbolic links if you're telling "ls" not to follow links) system call to get the information in question. This involves doing a lot of the same operations that an "open" does, namely looking up the pathname and reading the inode, in the case of a local file on a UNIX file system. >The only reason this has interested me is that it seems that, even for >long directory listings, the command takes a very short amount of time >to complete, considering all the file opening and closing I guess it's >doing. Your system is probably doing a reasonable job of caching information in memory. All UNIX implementations of local UNIX file systems with which I am familiar will cache data blocks of directory files, so to look up a file it may not have to read the directory blocks into memory. (In fact, since "ls" reads the directory itself, the blocks in question may already be *in* memory by the time it gets around to "stat"ting the file.) Similarly, blocks of the i-list will also be cached in memory. Since many inodes fit in a block, reading one block will get several inodes. Implementations of the 4.2BSD file system try to keep inodes for files within the same directory in the same blocks of the i-list, so the other inodes are more likely to be useful. In addition, there may be other caches, such as caches of directory entries (present in at least 4.3BSD, SunOS, and systems that have adopted recent versions of the SunOS VFS/NFS code) and caches of inodes that were used recently but are not currently in use. ----------------------------- From: Guy Harris Subject: Re: * Question Date: 30 Nov 88 19:41:56 GMT To: info-unix@sem.brl.mil >And, if "csh" lets this work as shown, why does it NOT work when >creating the file initially? Because a "starname" must match something that already exists. The starname "foo/*/bar" will match all files named "bar" in any subdirectory of "foo" (except those whose name begins with "."). When creating the file initially, it doesn't exist yet.... ----------------------------- From: "Richard A. O'Keefe" Subject: Re: ls -l Date: 30 Nov 88 13:20:03 GMT Sender: news@quintus.uucp Keywords: ls To: info-unix@sem.brl.mil In article <4952@boulder.Colorado.EDU> wu@spot.Colorado.EDU (WU SHI-KUEI) writes: >In article <838@nih-csl.UUCP> ted@nih-csl.UUCP (ted persky) writes: >>My question is this: does the "ls" program need to open each file, > >No - the inumbers are stored in the *directory* file, NOT in the individual >files. Try 'ls -i' and then 'od -c .' to prove this to yourself. The question was about "ls -l" (dash-lower-case-ELL) not about "ls -i" (dash-lower-case-EYE). ls -i does indeed have to inspect only the directory. ls -l, however, has to look a bit harder. There is a system call named stat() which says "tell me all about this file". It has to read the *inode*, but that is not the same as opening the *file*. That's done by the open() system call. For example, you can get stat() information about a file you do not have permission to read. ----------------------------- From: Mark Runyan Subject: Re: SCCS: how to handle multiple developers/streams Date: 29 Nov 88 22:24:07 GMT To: info-unix@sem.brl.mil >/ tpc@bnr-fos.UUCP (Tom Chmara) / 10:17 am Nov 24, 1988 / I'm not an expert in SCCS, so I may not be of any help, but you have found a problem that everyone using SCCS will encounter eventually... >1. Scenario: Building a new load. Problem: devoted developer has a > module checked out for editing. I don't WANT the new version; I want the > old one. "-c" gets the old version, "-G" specifies a new path into > which I dump the file. Ergo, I need a new copy of my source > directory structure? Or does every file need an "alias" for loadbuilding? I'm not sure I understand the problem the way it is phrased. (I also don't appear to have the "-G" option you mentioned). If your developers are all working in the same directory, the problems you face are very significant. SCCS alone may not be the solution. Perhaps each developer needs their own workspace (yes, that uses a lot of disk). With links, you could reduce the disk space, but managing the links would be difficult. >2. Scenario: Doing maintenance. A bug has been reported in existing > (read: non-current) software. Do I have to rebuild (recompile) the > world to be able to restore that environment? Do I have to maintain > a copy of the directory hierarchy for every released version? Again, separate work spaces are the only answer I see for this. Once you have found the fix, checking the fix in on a branch would be a way to store it. The environment is a *major* problem. While SCCS stores the source for a file, it doesn't keep the environment (i.e. compilers, header files, etc) needed to rebuild the exact bits. I strongly suggest that a database (which could be something as simple as a flat file and some awk scripts) be considered for keeping track of which revisions of which files and programs create a particular environment. Storing the old compilers, loaders, etc. into special directories might be required. >2. Scenario: Doing development. Do I need to do development in the > current directory (i.e. parent to SCCS directory) and aggravate the > loadbuilders (see #1)? What happens if two of us are doing development > in the same directory? I'd like to use the old (read: loadbuilt) > objects to avoid having to recompile the world; so would s/he. > We're constantly going to see each other's sources. This looks like > a problem for the Makefiles... Unless I actively sccs info each > subdirectory, I don't know who else is doing development -- and that > information itself is volatile... If the SCCS directory in *your* working directory is simply a link (symbolic or otherwise) to the "real" SCCS directory, each work space will use the same SCCS files but be separate. This uses a *lot* of disk space when someone checks everything out. One solution to this is to have a program which manages links (i.e. everything is checked out into some location and linked. When you want your own copy, break the link. Need a way to keep track of which are broken links and which aren't). >I DO know that both SUN & HP use SCCS at some stage of their development >efforts, so presumably maintenance of old software streams is a subject >near (though maybe not dear) to their respective hearts. Others are also >likely to be equally knowledgeable. I'm slowly going nuts trying to envision >parallel "shadow" directories, (and subdirectories, and...). Is there >an easy way out? Is there a sane way out? What are my alternatives? Well... I don't think that either SUN or HP uses *just* SCCS. (I don't think HP uses SCCS too much, but I could be wrong :-) SCCS only provides management of the revisions of a file. Frontends and support programs must exist to handle work spaces and networking. Knowing this will start a "Holy War", I'll mention that RCS allows a person to manage a group of files, but again, RCS only manages revisions. The work space and networking ( and environment ) problems are not solved by either RCS or SCCS. If a solution exists, I would really like to hear about it... I believe that solutions may arise soon as software configuration becomes more important, but I'm not aware of any solution available to the customer at the moment. Mark Runyan ----------------------------- From: "William P. Reeder" Subject: Re: ls -l Date: 30 Nov 88 23:26:02 GMT Keywords: ls Posted: Wed Nov 30 17:26:02 1988 To: info-unix@sem.brl.mil In article <838@nih-csl.UUCP>, ted@nih-csl.UUCP (ted persky) writes: > it seems that, even for long directory listings, the command takes a very short > amount of time to complete, considering all the file opening and closing I guess My experience has been that ls can take a very long time to run on large directories. Several posters have already explained that ls doesn't have to open each file in the directory; but no one has talked about ls sorting the information before displaying it. I think one version of ls we had used a bubble sort, which made it unbearable in some directories (containing around 800 files). One of my (former) co-workers modified ls to use quicksort, and it helped a lot. -- DISCLAIMER: I speak only for myself, and usually only to myself. ----------------------------- From: Andrew Hume Subject: Re: fio library routines Date: 29 Nov 88 20:33:39 GMT To: info-unix@sem.brl.mil a bundle of the fio man page and macros is available via anonymous ftp at arpa.att.com robert elz (uunet!munnari!kre or something) has been talking to me about a public domain implementation. the whole source is 600 lines of code so it shouldn't be too hard. ----------------------------- From: Andrew Hume Subject: Re: fio library routines Date: 29 Nov 88 20:49:26 GMT To: info-unix@sem.brl.mil anyone who gets the mk distribution (from AT&T toolchest) has the fio source. ----------------------------- End of INFO-UNIX Digest ***********************