Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!yale!cmcl2!adm!news From: postmaster@ccf3.nrl.navy.mil (SMTP MAILER) Newsgroups: comp.unix.wizards Subject: Mail not delivered yet, still trying Message-ID: <22047@adm.BRL.MIL> Date: 11 Jan 90 19:39:10 GMT Sender: news@adm.BRL.MIL Lines: 658 ----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: 11 Jan 90 08:16:00 EST From: unix-wizards@BRL.MIL Subject: UNIX-WIZARDS Digest V9#043 To: "whitis" Return-Path: <@nrl3.arpa:unix-wizards-request@sem.brl.mil> Received: from nrl3.arpa by nrl3.arpa with SMTP ; Thu, 11 Jan 90 08:14:47 EST Received: from SEM.BRL.MIL by nrl3.arpa with SMTP ; Wed, 10 Jan 90 03:39:40 EST Received: from SEM.BRL.MIL by SEM.brl.MIL id aa03862; 10 Jan 90 3:00 EST Received: from sem.brl.mil by SEM.BRL.MIL id aa03781; 10 Jan 90 2:45 EST Date: Wed, 10 Jan 90 02:45:12 EST From: The Moderator (Mike Muuss) To: UNIX-WIZARDS@BRL.MIL Reply-To: UNIX-WIZARDS@BRL.MIL Subject: UNIX-WIZARDS Digest V9#043 Message-ID: <9001100245.aa03781@SEM.BRL.MIL> UNIX-WIZARDS Digest Wed, 10 Jan 1990 V9#043 Today's Topics: filenames with a '/' -- help Re: filenames with a '/' -- help yacc and lex Re: GNU Emacs, memory usage, releasing Re: fcntl/socket anomaly Re: How to delete a file with ^? chars in the name? Number of chars in input queue - terminal, keyboard Re: C Documentation Utility Needed Obtaining a unique, "unchangeable" number associated with an SGI workstation Re: new mscp code in Ultrix 3.1 (was Boot block trashed) Re: Access to UNIX-Related Publications Wanted: fast tar across ether ----------------------------------------------------------------- From: "Gregory S. Baber" Subject: filenames with a '/' -- help Date: 8 Jan 90 20:28:44 GMT To: unix-wizards@sem.brl.mil Hello, I moved some files from a Mac to a NeXT using a GatorBox, and then took the NeXT off the network. Some of the files that were on the Mac had a '/' as part of the actual filename. How do I delete these from the NeXT now without reconnecting to the network? When I try to delete the files by hand, the shell responds with "file does not exist" because it interprets the '/' as a directory indicator. I even tried to double quote the filename to no avail. Any ideas? Thanks, gregb -- Reply to: Gregory S. Baber Voice: (609) 520-5077 Dow Jones & Co., Inc. UUCP: ..princeton!dowjone!gregb Box 300 or ..uunet!warlock!gregb Princeton, N.J. 08543-0300 "So long, and thanks for all the fish" ----------------------------- From: "seth.zirin" Subject: Re: filenames with a '/' -- help Date: 9 Jan 90 18:20:31 GMT To: unix-wizards@sem.brl.mil In article <646@warlock.UUCP> gregb@dowjone.UUCP (Gregory S. Baber) writes: >and then took the NeXT off the network. Some of the files that were >on the Mac had a '/' as part of the actual filename. How do I delete >these from the NeXT now without reconnecting to the network? When I >try to delete the files by hand, the shell responds with "file does >not exist" because it interprets the '/' as a directory indicator. You have several options: 1) reformat the disk (JUST KIDDING!!) :-) 2) fsck the filesystem. some versions of fsck will not permit illegal characters in names. if your version of fsck cannot fix it, complain to your vendor about the bug in their fsck. 3) use fsdb to locate and edit the disk block that contains the filename with the '/'. Change the '/' to a more palatable character. WARNING: this is not for the weak-hearted! 4) copy everything else from the parent directory to a safe spot and iclear or unlink the parent directory and run fsck. if the bad name is a file (as opposed to a subdirectory), fsck will copy it to the lost+found and give it a civilized name. if you have a directory tree of bad subdirectory names, this will become a recursive process. the above procedures assume that the filesystem is mounted/unmounted appropriately. when you're all done and you haven't roached the whole filesystem or the entire disk, hold your head high; you've earned one star towards becoming a wizard. discussion of the other stars should be referred to /dev/null as we just finished that topic. Seth Zirin ----------------------------- From: Chuck Cartledge Subject: yacc and lex Keywords: yacc,lex,error checking Date: 8 Jan 90 20:51:49 GMT Followup-To: comp.lang.c To: unix-wizards@sem.brl.mil Pardon the cross posting, but I'm not sure where the answer is for this question. I would like to use a yacc/lex generated program segment as a operator input validation routine, rather then having to write my own from the ground up. What I am trying to generate either automatically via yacc/lex or with only minor manual mods, is a function that looks like this: valid_data (character_string, data_type, addr1, addr2, ...) Is there a way to get something like this?? Any help would be appreciated. Thanks. -- Chuck Cartledge (804)498-1012 (voice-play) chuck@virgil.UUCP EDO Corporation (804)424-1004 (voice-work) Virginia Operations 814 Greenbrier Circle, Chesapeake Va. 23320 ----------------------------- From: Peter da Silva Subject: Re: GNU Emacs, memory usage, releasing Keywords: GNU emacs malloc memory working set gap editor Date: 8 Jan 90 22:07:52 GMT To: unix-wizards@sem.brl.mil > >> I contend that in a "modern workstation environment" (e.g., Sun 3/60), > >> a simple buffer gap method is preferred over both paged buffer gap and > >> linked line. I leave it as an excercise for the reader to figure out > >> why. > >I'm not sure this is a valid conclusion. If 75K is the optimal file size > Where did this "75K" figure come from? I honestly don't remember. It was mentioned by someone in this forum. I do think, though, that for any given system there is such an optimal size. It may be that on your workstation that size is measured in megabytes... on others it may be a few K. I wonder how it feels on a NeXT that's paging over the network or onto the OD? > >for a buffer-gap solution, how about paged buffer-gap with 75K pages? Or > >to add a bit of compromise with some of today's brain-dead architectures > >perhaps 64K pages would work nearly as well. > In particular, I have had no trouble editing multi-megabyte files in > GNU Emacs on a Sun 3/280 w/8 MBytes of memory. Having "no trouble" with something doesn't mean you have the optimal solution. Just that you have *a* solution. -- _--_|\ Peter da Silva. +1 713 274 5180. . / \ Also or \_.--._/ v "Have you hugged your wolf today?" `-_-' ----------------------------- From: Jim Cathey Subject: Re: GNU Emacs, memory usage, releasing Keywords: GNU emacs malloc memory working set gap editor Date: 9 Jan 90 19:20:13 GMT Followup-To: comp.editors To: unix-wizards@sem.brl.mil >The better solution, made relatively easy by the reasonably modular and >layered structure of GNU emacs, would be to accept The Emacs Cookbook >recommendation (adopted by Jove and the MicroEmacs/Gnu family of editors) and >implement a linked list system. I would suggest just reading (or map, on the >operating systems that allow it) the file to be edited as a large lump of >virtual address space, then building a linked list of pointers to lines >therein, and then to allocate modified lines from ageneral purpose arena. >Informing the OS of the peculiar access patterns would also help, if >possible. So long as line-oriented operation preserved the ability of Gnu Emacs to edit binary files that have no 'lines' at all. The MicroEmacs we have here will choke on these (as does vi, ed, see, siv, and all the other editors we have), and MicroEmacs' line orientation is so badly implemented that if (at our site) the file is larger than about 50K it is _faster_ to start emacs on the file than MicroEmacs. MicroEmacs starts faster, but it reads files _much_ slower (fgets,malloc,strcpy). Somebody or other's master's thesis was on buffer styles (I got a copy with my copy of MINCE a few years ago), and his conclusion was that the gap method worked best. That may have been on a machine that wasn't DPV, though. Moving the gap by, say, 20 characters should affect at most two pages (four, if you assume it straddles a page boundary on both ends but this is true for any scheme and may be disregarded). A block with a line pointer array might also affect two pages (the block and the buffer array) so I don't offhand see the advantage. Jumping about wildly would touch a lot of pages, but the assumption is that you work a lot in one place. The gap approach makes it very quick to _save_ files, so the auto-save feature is unobtrusive. It would be absolutely useless if it took 5-10 seconds to rearrange the line-pointer and block mess to get it into savable form, or write a line at a time. If realloc can't do the right thing it should be replaced by one that can. I believe GNU isn't interested in supporting non-GNU machines (read VAX) to the extent that it corrupts the architecture of the program. I somewhat agree with them in that broken environments shouldn't be catered to, but repaired instead. It would be nice if emacs did sbrk- when it could. In our environment, we can also release holes in the _middle_ of the heap. We added an additional system call for it. This gets pages out of the swap space, but they'll be reallocated (and cleared to zero) if you touch in the hole. We have a limited virtual address space (2M on some machines, 4M on most others) so GNU can't edit those really big log files. I think only elle can of the editors I've experienced. I think it uses linked blocks. GNU Emacs _is_ awfully large, though, but I haven't noticed any machine eating behavior. Of course, we have a lot of smaller machines here, so few use it at once. Far more noticible is simultaneous compiles. +----------------+ ! II CCCCCC ! Jim Cathey ! II SSSSCC ! ISC-Bunker Ramo ! II CC ! TAF-C8; Spokane, WA 99220 ! IISSSS CC ! UUCP: uunet!isc-br!jimc (jimc@isc-br.iscs.com) ! II CCCCCC ! (509) 927-5757 +----------------+ "With excitement like this, who is needing enemas?" ----------------------------- From: Chris Torek Subject: Re: fcntl/socket anomaly Keywords: obscure behavior Date: 9 Jan 90 08:24:01 GMT To: unix-wizards@sem.brl.mil In article <129979@sun.Eng.Sun.COM> lm@snafu.Sun.COM (Larry McVoy) writes: >Those checks [applied by TIOCSPGRP] are inappropriate for the F_SETOWN. >For example, POSIX insists that the tty in question be your controlling tty. >That's both unecessary and unlikely for processes wanting SIGIO on a tty. Ah: this is different from what you said (or at least, what I understood) before. Now you seem to mean `any process should be allowed to ask for SIGIO on any file descriptor to which it can apply an fcntl, and should receive SIGIO signals whenever it could read from / write to that descriptor.' (This is a reasonable interpretation of what SIGIO should be, but would require major kernel restructuring, since per-file-descriptor flags can only be stored in a u. area.) >Suppose I have process A and process B. A does a F_SETOWN on some >socket and then goes on, expecting a SIGIO at some later time. B comes >along, and also does a F_SETOWN on the same socket. A has been >robbed. Ah. This, of course, is a property of the shared-ness of descriptors. A dup()ed descriptor (either with the dup() or dup2() system calls, or simply shared across fork+exec) has only one underlying object, and (for reasons having to do with the basic kernel structure) signals have to refer to the underlying object%, hence are shared. Fortunately, two different endpoints on a socket are not shared. A program (your `A') that passes its own socket endpoint to another program (your `B') has explicitly---well, okay, implicitly---given control of the socket to the second program. For instance, `B' could issue a shutdown on the socket as well. Thus, I think this objection does not apply. (It *does* apply to tty devices.) ----- % Actually, they refer to the object underlying the underlying object, in the case of inodes; but this, at least, could be changed in principle. (Thread a linked list of signal info through the file table.) Then you have the problem of *giving up* SIGIO signals for a descriptor. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris ----------------------------- From: Larry McVoy Subject: Re: fcntl/socket anomaly Keywords: obscure behavior Date: 9 Jan 90 21:40:16 GMT Sender: news@sun.eng.sun.com To: unix-wizards@sem.brl.mil In article <21710@mimsy.umd.edu> chris@mimsy.umd.edu (Chris Torek) writes: >In article <129979@sun.Eng.Sun.COM> lm@snafu.Sun.COM (Larry McVoy) writes: >>Those checks [applied by TIOCSPGRP] are inappropriate for the F_SETOWN. >>For example, POSIX insists that the tty in question be your controlling tty. >>That's both unecessary and unlikely for processes wanting SIGIO on a tty. > >Ah: this is different from what you said (or at least, what I understood) >before. Now you seem to mean `any process should be allowed to ask for >SIGIO on any file descriptor to which it can apply an fcntl, and should >receive SIGIO signals whenever it could read from / write to that descriptor.' Well, while I agree that this would be nice, it's not at all what I meant and I think you know it. SIGIO is commonly applied to tty's. The point you made about permission checks is bogus because POSIX won't let you get SIGIO on anything but your controlling terminal if you continue with this braindead implementation that calls TIOCSPGRP. >>Suppose I have process A and process B. A does a F_SETOWN on some >>socket and then goes on, expecting a SIGIO at some later time. B comes >>along, and also does a F_SETOWN on the same socket. A has been >>robbed. > >Ah. This, of course, is a property of the shared-ness of descriptors. Not really. If sockets can be named in the file system (Unix domain) then you can get at it by opeing the file (like the printer for instance). >A dup()ed descriptor (either with the dup() or dup2() system calls, >or simply shared across fork+exec) has only one underlying object, >and (for reasons having to do with the basic kernel structure) signals >have to refer to the underlying object%, hence are shared. > >Thus, I think this objection does not apply. (It *does* apply to tty >devices.) This is missing the point completely. I don't care (and neither do you) that cooperating processes can hurt each other (a new definition of cooperating :-) It's the tty and named socket case that's broken. Let's take this offline, Chris - I think the horse is dead.... --- What I say is my opinion. I am not paid to speak for Sun, I'm paid to hack. Larry McVoy, Sun Microsystems (415) 336-7627 ...!sun!lm or lm@sun.com ----------------------------- From: currey tom 76327 Subject: Re: How to delete a file with ^? chars in the name? Date: 9 Jan 90 14:22:36 GMT Sender: news@trantor.harris-atd.com To: unix-wizards@sem.brl.mil You asked how to delete a file with deleted characters. This depends on the system you're using. Here are 2 ways: Using the backslash for the meanings try: " rm \\\H12.b " { is delete key} or last resort method Copy all other files into a temporary directory and " rm -r " the copy them back after making a new directory. ----------------------------- From: Larry McVoy Subject: Re: How to delete a file with ^? chars in the name? Date: 9 Jan 90 21:44:45 GMT Sender: news@sun.eng.sun.com To: unix-wizards@sem.brl.mil In article <7711@unix.SRI.COM> ubi@ginger.sri.com (Ron Ueberschaer x4399) writes: >I have a file which is named ^?^?^?H01.b (delete character?) and can't >find a way to delete it. An ls -s on the directory produces: > > .. ... (other files) > 1 ???H01.b > >If I do an ls *.b, it lists the other .b files, but complains: > > H01.b not found > >I've tried: > > rm -i * (to selectively delete everything) > rm "???H01.b" > rm "^v^?^v^?^v^?H01.b" (control-v delete ...) > >and nothing seems to work. $ cat > xxx.c #include main() { char buf[255]; while (gets(buf)) if (unlink(buf)) perror(buf); } ^D $ cc xxx.c $ a.out ????H01.b ^D --- What I say is my opinion. I am not paid to speak for Sun, I'm paid to hack. Larry McVoy, Sun Microsystems (415) 336-7627 ...!sun!lm or lm@sun.com ----------------------------- From: "John W. DeBoskey" Subject: Number of chars in input queue - terminal, keyboard Keywords: QUEUE TERM KEYBOARD ISC 1.0.6 Date: 9 Jan 90 16:42:00 GMT To: unix-wizards@sem.brl.mil Hello, The subject almost says it all. I'm running ISC 1.0.6. I want to find out how many characters are available to read from the terminal if there are any. ie: avail = in_queue(term_id). A BSD answer is to use FIONREAD, but sVr3 doesn't have it, and I've been unable to duplicate it. Please don't tell me to RTFM or read the monthly intros. I have and they don't help. I'm starting to think the only way I can do this is to actually issue a read, and do my own internal buffering, but I DON'T really want to do this. If anyone has some ideas, or knows a way that isn't doc'd, please let me know. I'd really appreciate it. Thanks!! John W De Boskey jwd@sas.UUCP (w) jwd%sas@rti.rti.org jwd@baggins.UUCP (h) jwd%baggins@mcnc.mcnc.org ----------------------------- From: Mike Ewan Subject: Re: C Documentation Utility Needed Date: 9 Jan 90 16:53:45 GMT Followup-To: comp.unix.wizards To: unix-wizards@sem.brl.mil In article <10761@cadnetix.COM> rusty@cadnetix.COM (Rusty Carruth) writes: >In article <625@h.cs.wvu.wvnet.edu> dymm@b.cs.wvu.wvnet.edu (David Dymm) writes: >> >>I am looking for a utility to help in the documentation of C code. >>[...] > >Well, this will probably not help as much as I would like, but there >is a program available for the PC family which does pretty-printing >and such, and also can create the tree info you wanted. I THINK >it was by Polytron, but I could be wrong. I'll try to find out >and post again. If anyone else knows of the actual company name, >you might be really lucky and that company may have ported it to >unix by now... The company is Sage/Polytron, 1100 nw 167th Pl, Beaverton OR 97006 (503) 645-1150 I havn't used their PolyDoc product but have used their PVCS (RCS clone). I'm pleased with the product. They have been porting some of the products to Unix. If PolyDoc isn't ported you could always download to a PC run the thing and then up load. -- Michael Ewan (503)627-6468 Internet: mike@raven.USS.TEK.COM Unix Systems Support UUCP: ...!tektronix!puffin!raven!mike Tektronix, Inc. Compuserv: 73747,2304 "Fig Newton: The force required to accelerate a fig 39.37 inches/sec."--J. Hart ----------------------------- From: Tony Rems Subject: Re: C Documentation Utility Needed Date: 10 Jan 90 01:24:00 GMT To: unix-wizards@sem.brl.mil In article <625@h.cs.wvu.wvnet.edu> dymm@b.cs.wvu.wvnet.edu (David Dymm) writes: > >I am looking for a utility to help in the documentation of C code. > >Input: Multiple 'C' files. > >Output: A cross reference report showing the call hierarchy of > all functions. > Thus, the report might be in the form of a tree where > each function is listed showing from where it is called > and perhaps how many times it is called. > > >David Dymm Project Manager > >USMAIL: Bell Atlantic Knowledge Systems, > 145 Fayette Street, Morgantown, WV 26505 >PHONE: 304 291-2651 (8:30-4:30 EST) >USENET: {allegra,bellcore, cadre,idis,psuvax1}!pitt!wvucsb!dymm >INTERNET: dymm@b.cs.wvu.wvnet.edu There is a set of tools from McCabe & Associates called Battlemap, ACT & the Inference Engine. These tools are designed to measure complexity of C code (as well as code in other languages) and it runs under UNIX on Sun and a few other platforms. It can produce the calling structure of a pieced of code as well as the internal structure of the code. It can produce a report or a graph (or both) and using the inference engine it produce cross reference information on the internal structure of the code - including called-bys called-from calls-to and number of calls. Although, I found it rather limited in its capacity as a test tool - which was its purpose, it sounds like it might suit your purposes. If you'd like any more info, send me some e-mail. -Tony ----------------------------- From: Andrew Simms Subject: Obtaining a unique, "unchangeable" number associated with an SGI workstation Keywords: copy protection, hostids, unique identifiers Date: 9 Jan 90 18:23:06 GMT Sender: news@phoenix.princeton.edu Followup-To: comp.sys.sgi To: unix-wizards@sem.brl.mil Some of the folks I work for would like to make a reasonably secure scheme to insure their product runs only on machines they are licensed to run on. To do this, they would like to obtain a read-only number (such as a motherboard serial number) that could be used as a key to operate the software only on that machine. I know mathematica on the Irises has a program called mathinfo that generates a unique number but I have no idea what it does to get it. If there is sufficient interest, I will be happy to post a summary of responses emailed to me. p.s. Ethernet addresses won't quite do it, since it needs to run on machines without ethernet boards. ---------------------------------------------------------------------- Andrew Simms ams@acm.princeton.edu System Administrator Program in Applied and Computational Math Princeton University Princeton, NJ 08544 609/258-5324 or 609/258-6227 609/258-1054 (fax) ----------------------------- From: Greg Wohletz Subject: Re: new mscp code in Ultrix 3.1 (was Boot block trashed) Date: 9 Jan 90 20:15:35 GMT Sender: news@jimi.cs.unlv.edu To: unix-wizards@sem.brl.mil In article <1444@jimi.cs.unlv.edu>, I write: > We have three microvax II's that we use as fileservers. Each has 3 > Wren V's and an Exabyte hooked into a Sigma scsi controller (it > emulates a uda and tms controller). They also have a Dec uda > controller hooked to an rd52 and two rx50's (yes we've had these > machines for a while...) on them. We have been running with this > configuration under Ultrix 2.0 without many problems (well a few nfs > bugs, but nothing major). Recently we got Ultrix 3.1. I installed it > on one of our microvax's and everything seemed to be going fine, I > could use the disks, and read from the Exabyte. However, when I tried > to dump the root filesystem to the Exabyte I got a write error, then > some message like ``mscp resynching controller uq2'' at that point the > system locked up. Well, I've investigated the situation a bit further, and I have discovered that (surprise, surprise) one difference between 2.0 and 3.1 is that all of the disk and tape drive stuff appears to have be re-written. Now everything (except for non-uda type drives and non-tmscp tapes) goes through this new mscp code (or at least that is what it looks like to me). Anyway looking at the code didn't reveal anything obvious, however I have noticed that I can't dump to the trusty (?) old rx50's. The first volume of the dump works fine, but if you so much as open the door to the floppy when dump asks you to insert the next volume all subsequent attempts to write to the floppy will fail (if you leave the same floppy in (without opening the drive door) for ALL of the volumes it will work...). I suspect that this problem is related to the same bug. I think at this point I'm almost convinced that it is a software bug, and not a problem with the Sigma controller, but I could be wrong. So the question is, will someone from DEC tell me if there is a known/fixable bug in 3.1 that would cause this behavior? Would if be possible to graft in the old tmscp code from 2.0 without an inordinate amount of pain? ANY information would be greatly appreciated. --Greg greg@unlv.edu <@relay.cs.net:greg@unlv.edu> ----------------------------- From: Barry Shein Subject: Re: Access to UNIX-Related Publications Date: 9 Jan 90 23:47:04 GMT To: unix-wizards@sem.brl.mil >Any of the luminaries out there know how to get 'awk' (not nawk) to ouput a >single-quote character ( ascii 0x27 ). sq = sprintf("%c",39) print sq -- -Barry Shein Software Tool & Die, Purveyors to the Trade | bzs@world.std.com 1330 Beacon St, Brookline, MA 02146, (617) 739-0202 | {xylogics,uunet}world!bzs ----------------------------- From: Lee McLoughlin Subject: Wanted: fast tar across ether Date: 10 Jan 90 02:02:18 GMT Sender: news@doc.ic.ac.uk To: unix-wizards@sem.brl.mil I am in urgent need of a way to write tar output to a remote tape drive, an exabyte, over ethernet very quickly - preferably allowing the exabyte to stream. I currently use the gnu-tar, which does a pretty good job but I really something faster. If necessary I will write my own one - so any suggestions about how best to do this are welcome. Lee ----------------------------- End of UNIX-WIZARDS Digest **************************