Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!unmvax!aplcen!haven!adm!xadmx!postmaster@urbana.mcd.mot.com From: postmaster@urbana.mcd.mot.com Newsgroups: comp.unix.wizards Subject: mail to xenurus.gould.com Message-ID: <20213@adm.BRL.MIL> Date: 11 Jul 89 14:58:48 GMT Sender: news@adm.BRL.MIL Lines: 682 The enclosed mail message was addressed to a system which is no longer in service. We have attempted to forward your mail to the correct recipient(s). If this is not possible, you will recieve additional mail at the time of failure. In the future, please use the system name "urbana.mcd.mot.com" instead. Please correct any mailing lists or alias files that may reference any of the following obsolete system names: xenurus.gould.com fang.gould.com fang.urbana.gould.com vger.urbana.gould.com ccvaxa.gould.com ccvaxa.urbana.gould.com burt.urbana.gould.com mycroft.urbana.gould.com If you have any further problems or questions about mail to this site, please contact postmaster@urbana.mcd.mot.com. thank you for your cooperation, postmaster@urbana.mcd.mot.com Motorola Microcomputer Division, Urbana Design Center ---------- text of forwarded message: Received: from sem.brl.mil by placebo (5.61/1.34) id AA04291; Mon, 10 Jul 89 21:32:07 -0500 Received: by SEM.BRL.MIL id al11312; 10 Jul 89 15:26 EDT Received: from SEM.BRL.MIL by SEM.brl.MIL id aa04939; 10 Jul 89 3:16 EDT Received: from sem.brl.mil by SEM.BRL.MIL id aa04832; 10 Jul 89 2:45 EDT Date: Mon, 10 Jul 89 02:45:20 EST From: The Moderator (Mike Muuss) To: UNIX-WIZARDS@BRL.MIL Reply-To: UNIX-WIZARDS@BRL.MIL Subject: UNIX-WIZARDS Digest V7#125 Message-Id: <8907100245.aa04832@SEM.BRL.MIL> UNIX-WIZARDS Digest Mon, 10 Jul 1989 V7#125 Today's Topics: gath Re: Algorithm needed: reading/writing a large file ftruncate broken? - Sun-based NFS Socket Extensibility to non TCP/IP uucp delivery order? Re: What kinds of things would you want in the GNU OS? Re: SLIP compression... Re: Using the uucp daemon (TCP/IP) on System V.3 with TCP/IP Re: chown (was: at files and permissions) Re: Convert string time into seconds? Re: at files and permissions Re: chown (was: at files and permissions) Re: scsi rll trade off questions? Re: Using the uucp daemon (TCP/IP) on System V.3 with TCP/IP ----------------------------------------------------------------- From: "barbara.tongue" Subject: gath Date: 8 Jul 89 19:30:28 GMT Keywords: help! To: unix-wizards@sem.brl.mil Folks, In one of the tools directoryies on my machine, I discovered the executable "gath." Now, from what I've heard, gath is a tool which "gathers" files, allows shell execution if lines are prefaced with ~$, and can be used in combination with troffed files. Here is my question - Let's say that I have dynamic flat-file database, whose fields can be any combination of 17 variables. I want to pipe that into troff and get out a clean table with the headers correctly inserted. With definite input, that is no problem; for example, I've written into my .tbl file what the header names are and in what file the data is located. The problem occurs when I want to switch to using $1 as my file name; the command gath file.tbl file.data defines $1 as null. (I'm calling $1 from file.tbl; I assume that in itself is a problem.) Does anyone know where the source code can be found? I have no man page for this executable; can anyone help? Much, much *much* thanks in advance, -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %% The Speaking Tongue, AT&T %% C Code. C Code Run. Run, Code, RUN! %% %% (..!att)!feathers!bgt %% PLEASE!!!! %% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ----------------------------- From: David Quarles Subject: ... HELP HELP ... TROUBLE PRINTING WITH eroff ... Date: 8 Jul 89 14:29:39 GMT Keywords: eroff printing more than one page To: unix-wizards@sem.brl.mil =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= I need some help on getting eroff to print the text (all of it) from a regular text file on UNIX. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= I have the book "Preparing documents with UNIX" by Brown et.al. but just cannot figure out how to get the text to print continuously from page to page. This book covers troff and nroff but not 'eroff'. I had hoped there would be something in it that would help. In talking to a couple of others at this site, this 'eroff' is apparently third party software for UNIX. What happens is that several lines get left off at the bottom of a page and then the second page does not have the missing lines but has just somehow skipped text. ALL I WANT TO DO IS TO TAKE A TEXTFILE AND PRINT WITH eroff (for our HP Laserjet). This program eroff does a very nice job with margins and font styles. ANY IDEAS OUT THERE ?? ANY ADVICE WILL BE GREATLY APPRECIATED !! =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= PLEASE email since our UNIX system purges the news sometimes before I get a chance to read it ... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= =-=-= Email: david@jc3b21.UUCP -=-=-=-=-=-=-=-= Dave =-=-=-=-=-=-=-=-=-=-= EOT ----------------------------- From: Jeffrey Kegler Subject: Re: Algorithm needed: reading/writing a large file Date: 9 Jul 89 06:05:41 GMT To: unix-wizards@sem.brl.mil In article <207@larry.sal.wisc.edu> jwp@larry.sal.wisc.edu.UUCP (Jeffrey W Percival) writes: => Please be careful with your paraphrasing. I certainly promise to try. => My question was about optimizing the process of rearranging a disk file => according to a *given* mapping. Jeffrey P. (no relation) had implemented a suggestion made in the AT&T Bell Laboratories Technical Journal, by J. P. Linderman, p. 258. He extracted the keys and record locations of an unsorted file (call it U), sorted them, and them constructed the sorted file (call it S), only to find the random seeks involved in the last phase horrifyingly slow. => One helpful person suggested reading sequentially and writing randomly, => rather than vice-versa, That would have been my first thought. => and I tried that but it didn't help. I guess => the benefit gained from using the input stream buffering was canceled => out by the effective loss of the output stream buffering. Oh well. As a second try, allocate enough memory for N full length records, and two arrays to be sorted together of N keys and N record locations. Go through the sorted keys and find the key and locations in U of the first N records in the *sorted* file. Sort them by record location in U, the unsorted file, and read them in, in order by location in U, writing them in memory in sorted order by key in the array of full length records. Then write those records out. Repeat until all records are written. This will involve 1 sequential pass to write file S, and M/N sequential passes to read file U. A further improvement is to calculate how many sequential reads cost the same as a random seek. Call that ratio R. Whenever performing the algorithm above would require more than R sequential reads (this is easily determined from the difference in the record locations), perform a seek. My guess at R for UNIX is around 2.5 times number of records per block. Obviously the larger N the better this will work. Note your original try is this algorithm in the special case where N is 1. If we could run this algorithm in terms of physical disk block instead of logical file location, this algorithm could really hum. Further optimizations suggest themselves, but enough already.-- Jeffrey Kegler, President, Algorists, jeffrey@algor2.UU.NET or uunet!algor2!jeffrey 1762 Wainwright DR, Reston VA 22090 ----------------------------- From: der Mouse Subject: ftruncate broken? - Sun-based NFS Date: 9 Jul 89 05:13:16 GMT To: unix-wizards@sem.brl.mil The ftruncate() call appears to be broken on at least some systems with NFS implementations based on Sun's. I've tried this on a Sun-3 with release 3.5 and on a VAX running mtXinu 4.3+NFS. I also tried it on a MicroVAX running real 4.3, and it did not exhibit the broken behavior. But it's not directly an NFS problem, because it happens even when the file is on a ufs filesystem. The problem is that ftruncate() fails if the file modes prohibit writing, even if the file descriptor used does permit writing. For example, try the following program on a handy Sun. Notice that (unless you try it as super-user), the ftruncate call fails. Try it on a 4.3 machine, though, and everything's fine. (I checked the Sun manpage, and there's not even a note in the BUGS section warning about this, so presumably someone thinks it should work the way it does on 4.3.) Anybody have a simple fix? (Patch a couple of bytes to noops somewhere in the OBJ/ files perhaps?) Will it be fixed in newer releases (4.x)? I'm about ready to try to work out a fix on the mtXinu system, to which we have source, but that's not much help on the Suns. #include int fd; char junk[8192]; main() { unlink("test.file"); fd = open("test.file",O_RDWR|O_CREAT|O_TRUNC,0666); if (fd < 0) { perror("open/create test.file"); exit(1); } if (write(fd,&junk[0],8192) != 8192) { perror("write #1"); exit(1); } if (fchmod(fd,0444) < 0) { perror("fchmod"); exit(1); } if (write(fd,&junk[0],8192) != 8192) { perror("write #2"); exit(1); } if (ftruncate(fd,(unsigned long int)16000) < 0) { perror("ftruncate"); exit(1); } if (close(fd) < 0) { perror("close"); exit(1); } exit(0); } der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu ----------------------------- From: Paul Hardiman Subject: Socket Extensibility to non TCP/IP Date: 7 Jul 89 19:34:20 GMT To: unix-wizards@sem.brl.mil What is the story on using sockets on more than just TCP/IP. Like for instance, one of the OSI protocals, MAP or TOP; and X.25.-- Paul Hardiman ...!uw-beaver!ssc-vax!voodoo!bcsfse!paul The above views are strictly my own. ============================================================ ----------------------------- From: Jim Rosenberg Subject: uucp delivery order? Date: 9 Jul 89 03:27:38 GMT To: unix-wizards@sem.brl.mil I asked this question once before & got a thundering silence -- sorry if I missed any replies, but I *still need to know*. How can I guarantee that uucp will deliver jobs to a remote system in the order in which they were queued? More specifically, how can I issue a series of uux requests and be sure that the uuxqt at the remote end will execute them in the same order? I have HDB at one end, and by the time the system is in production will have HDB at the other end too. The system will be Sytem V.3 in production, if that makes any difference. My *very strong impression* is that uucico simply uses the ordering you would get by doing an ls -f C.* on the spool directory. This is not at all guaranteed to give the same order as ls -rt C.*, which is what I'd like. If this suspicion is correct, then I could try to solve my problem by filling up "holes" in the spool directory before issuing the uux request -- *PROVIDED* I could completely lock any uuoids in the interim which might remove any files from the spool directory. (I really don't care if some other process sneaks in "intervening" jobs -- that doesn't matter. The process that will create the jobs I'm concerned about has its own locking that guarantees only one instance can run at once.) For old-style uucp this is a dire pain, since all sites share the same spool directory. That would mean locking uucp across all sites. But for HDB I could at least lock the site in question, fill up holes in the spool directory, then unlock the site. Is this good enough? Is there a simpler way? Somehow this makes me nervous. Does the cleanup daemon honor a site lock? Tampering with directory slots like this seems like a real kludge, and there's no way I can think of to lock the directory in a truly safe way that's guaranteed to be reliable. Not to mention the problem that even if I can guarantee that uucico on the sending end sends jobs in chronological order, I still don't know if uuxqt on the receiving end will *run* them in the same order! If uuxqt runs jobs in ls -f order for the receiver's spool directory, then no amount of clever fakery on the sending end will help one wit. If this is how uuxqt works then I fear there may simply be no way to do this. Aargh, am I asking for the impossible? This seems like such a straightforward thing to want to do, I'd have thought this issue would have been old hat. I notice news articles all the time where a reply has a lower article number than the article to which it's replying; I wonder how much of that is from uucico delivering jobs "out of order". Any help appreciated. -- Jim Rosenberg CIS: 71515,124 decvax!idis! \ WELL: jer allegra! ---- pitt!amanue!jr BIX: jrosenberg uunet!cmcl2!cadre! / ----------------------------- From: Andrew Hume Subject: Re: What kinds of things would you want in the GNU OS? Date: 9 Jul 89 06:06:43 GMT To: unix-wizards@sem.brl.mil In article <1050@etnibsd.UUCP>, vsh@etnibsd.UUCP (Steve Harris) writes: > In article <1549@salgado.Solbourne.COM> dworkin@Solbourne.com (Dieter Muller) writes: > >I'd *really* like a sane tty driver. > > Hear hear!! At a former job we talked a lot about how we would rewrite > the tty driver. One idea was to give the user, via ioctl's, access to > the uart (or whatever serial-line multiplexer you have). One ioctl to and so on..... this is plainly false advertising. it is plausible to give complete control of a uart to a user. it is NOT plausible to do so under the guise of a sane tty driver. normally, you would implement a new device (say /dev/uart). ----------------------------- From: "Steven M. Bellovin" Subject: Re: SLIP compression... Date: 9 Jul 89 12:46:42 GMT To: unix-wizards@sem.brl.mil In article <5108@oregon.uoregon.edu>, jqj@oregon.uoregon.edu (JQ Johnson) writes: > One possible place to put compression is in the modem itself. The problem with putting compression in the modem is that you're still limited by the 9.6Kbps or 19.2Kbps pipe from the CPU to the modem. (Assuming an external modem, of course.) ----------------------------- From: Cliff Spencer Subject: Re: Using the uucp daemon (TCP/IP) on System V.3 with TCP/IP Date: 9 Jul 89 12:38:08 GMT Keywords: UUCP TCP/IP uucpd uucico sockets BSD4.3 SysV.3 To: unix-wizards@sem.brl.mil >>Porting BSD 4.3 UUCP daemon has already been done several times for different >>incarnations of TCP/IP implementations for system V Unix's. Unfortunately >>none of them are "free" that I know of. > >I only need the patches, I have the BSD4.3 uucpd source... What's the big mystery? Doesn't the daemon just spawn /usr/lib/uucp/uucico? -cliff ----------------------------- From: Barry Shein Subject: Re: chown (was: at files and permissions) Date: 9 Jul 89 15:38:15 GMT To: unix-wizards@sem.brl.mil From: gwyn@smoke.BRL.MIL (Doug Gwyn) >There seem to me to be two valid services that can be performed >by a disk "quota" system. One of them is to prevent runaway disk >consumption such as > cat x >> x >and the other is to keep users from accumulating junk that fills >the available disk. The first problem is dealt with adequately >by a resource limit mechanism a la ulimit, or more reliably by a >"dynamic" quota monitor attached to the specific session. The >second problem can be dealt with administratively, with periodic >use of "du|sort -rn" to find where the problems are. Realistic >long-term storage quotas really have to be negotiated between the >users and the system administrator anyway. These methods of >providing disk quota services do not encounter the scenario that >you described for the UID-based quota scheme when the file owner >is allowed to chown his own file. No, it can't be dealt with with "du|sort -rn" except on very small systems where you can probably just say "someone's hogging the disk" loudly and get the same effect, cause everyone's in the same room anyhow (ok, I exaggerate, but small systems with perhaps a hundred or two entries in the password file.) Or, of course, where you charge hard currency for disk space so the system has built-in feedback which makes such problems relatively rare (on one system like that at Harvard I was the "disk hog", but my funds solved the problem simply enough, they bought me my own washing machine, no tears.) Consider the system Rob Pike was describing in his recent USENIX talk. One major component was a large, organization-wide file server. This is the type of system that easily has tens of thousands of accounts (that's not unusual, I worked with a non-unix system over the last few years that had over 15,000 login accounts in the password file.) You can have dozens if not hundreds of people using more than what was decided was their fair share of disk every day. So you run this script and send them mail. So what? So twenty of them went over their fair share and won't be back for weeks to see your mail (negligently or otherwise, they may have thought they had a good reason to do whatever they did) are way over quota and the disk is busting at the seams on some partitions. Another ten are ignoring you. Don't tell me, you start moving some of their stuff off to tape. Oh what fun, let's have about two dozen people to run this system just to handle sending and answering disk quota mail, putting things to tape, dealing with irate users who find they were put to tape and are quite sure you are mistaken and have inconvenienced them (or believe they can play the political game to make you never do that to them again), get the stuff off tape, deal with people who are quite sure something has gone wrong in this restoral not to mention a phone call or two about how it took so damn long and they now have a dozen people idle which is costing them about a thousand dollars an hour while you deal with the others who are being difficult (ie. human), etc etc etc. Sh*t Doug, I'd own your whole disk farm just by making you do things by written, signed memo. You'd spend your weekends proposing budgets for another dozen secretaries. Obviously little systems don't need quotas very badly (tho, hey, they solve both problems you describe with one model, why introduce two systems where one will do?) The correct answer is that if you personally shouldn't be constrained to quotas either you should have infinite quotas or access to some (set[gu]id) program which lets you set your own quotas (so problem #1, the accidental overrun is still averted, if desirable.) Disk is a finite, valuable resource. Many organizations must manage their disk with many users from diverse administrative domains, and manage it without any realistic chargeback scheme (ie. the disk is essentially or actually free* as far as any individual user is concerned.) The simplest, most obvious way to do this is to assign disk quotas and have the software enforce these quotas automatically instead of turning some poor sap into your local disk slave heavy. My suspicion is you've never managed large systems like this or you wouldn't even dream of suggesting to just send mail to offenders. And they're not rare (hint: just about every university has at least one, if not a few dozen, such systems.) -------------------- * In fact it's often worse than "free" since the disk is being paid for out of overhead by everyone so anything you can grab for yourself is a boon to you, kinda like taxes, you actually can win as long as you're getting more than your fair share and someone else isn't. Sorry, but that's life, you don't fix it by removing quotas. -- -Barry Shein Software Tool & Die, Purveyors to the Trade 1330 Beacon Street, Brookline, MA 02146, (617) 739-0202 Internet: bzs@skuld.std.com UUCP: encore!xylogics!skuld!bzs or uunet!skuld!bzs ----------------------------- From: Wayne Krone Subject: Re: Convert string time into seconds? Date: 7 Jul 89 21:27:09 GMT To: unix-wizards@sem.brl.mil > I have a user entered time/date in the format: > yymmddhhmmss > I need to convert this into seconds since the epoch and If you have ANSI C libraries, convert the yymmddhhmmss into a tm struct and then use mktime() to convert that into seconds since the epoch. Wayne ----------------------------- From: "Brandon S. Allbery" Subject: Re: at files and permissions Date: 9 Jul 89 15:36:14 GMT Followup-To: comp.unix.questions To: unix-wizards@sem.brl.mil As quoted from <669@lzaz.ATT.COM> by hutch@lzaz.ATT.COM (R.HUTCHISON): +--------------- | About "at" requiring "root" permission, I guess it needs it to write | into the "atjobs" directory. +--------------- at needs root permissions so it can setuid() itself to the owner of the at job file, so it can execute the job as the user who submitted it. ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@ncoast.org uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu Send comp.sources.misc submissions to comp-sources-misc@ NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser ----------------------------- From: Bill Carpenter Subject: Re: chown (was: at files and permissions) Date: 9 Jul 89 11:44:25 GMT Sender: bill@cbnewsh.att.com To: unix-wizards@sem.brl.mil In article <10501@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes: > So now the issue becomes: Is the BSD disk quota system bogus? > ... > second problem can be dealt with administratively, with periodic > use of "du|sort -rn" to find where the problems are. Realistic > long-term storage quotas really have to be negotiated between the > users and the system administrator anyway. These methods of > providing disk quota services do not encounter the scenario that > you described for the UID-based quota scheme when the file owner > is allowed to chown his own file. My guess is that the reason that quotas are not handled administratively is because it is too much hassle for some people. Far be it from me to judge whether automating penalites is justified on somebody else's system. However, if I were building a tool to count up how much disk was being used by various parties, I might just make the owner of a directory the responsible person for all the blocks in the normal files immediately under it. Sure, some people leave directories open to being filled up by sneaky people who want to evade disk quotas, but at least my scheme would make the directory owner a co-conspirator. Losing chown to get disk quotas seems about as wise as having an imposed low ulimit. -- Bill Carpenter att!ho5cad!wjc or attmail!bill ----------------------------- From: Tatu Yl|nen Subject: Re: scsi rll trade off questions? Date: 9 Jul 89 18:52:30 GMT Sender: news@santra.uucp To: unix-wizards@sem.brl.mil In article <14978@ut-emx.UUCP> allred@ut-emx.UUCP (Kevin L. Allred) writes: I'm putting together a low end workstation for my personal use at home. It will have a 386SX, 4MB memory and monochrome VGA graphics. Initially I plan to just run MSDOS, but soon I would like to run UNIX. I currently am considering hard drives in the range of 65 to 80 MB. I was only considering an RLL drive with 1:1 interleve controller until I had pointed out to me that Segate has recently started marketing a low cost SCSI addaptor (ST01 and ST02) suitable for use with its ST296N 80MB hard disk. This combination reportedly offeres about 750 KB/sec transfer rate, which is comparable to the 1:1 interleve RLL transfer rate, and it is more cost effective. Apparently the SCSI addaptor works fine under DOS, but I have already had related to me that it probably won't work with UNIX because of lack of drivers (I heard that was a problem common to most SCSI boards even the expensive intelligent ones like the WD7000). Are the various UNIX vendors developing drivers, so that I don't need to worry about this, or should I stick with the RLL controller and disks? I have used a Priam 738 SCSI disk (337 MB, 20ms) with the Seagate ST-01 controller for about one and a half years now. For the first half an year I used it under msdos in a slow 16-MHz 386 machine. Coretest and others reported transfer rates in the range of 750 KB/sec. (Check that you have the 0WS jumper installed - without it I only got something like 500 KB/sec). About an year ago I purchased Microport Unix System V/386, and wrote a device driver for the controller and the disk. I posted the driver here about two weeks ago. The driver has been in use on my system and a couple of other systems for over an year. The driver has proved to be very reliable (some problems were reported with Seagate ST227N when using 1KB sectors, but those disappeared by formatting the drive to use 512 byte sectors). The driver supports multiple drives and partitions. My disk is partitioned in three partitions: 10 MB /tmp, 20 MB /u2 and 307 MB /u. (BTW, I have never had any problems with large partitions. Some people have reported problems in the news.) I cannot give exact transfer rates under unix. With my original driver I only got something like 160 KB/sec while reading a large (10-20 MB) file with dd -bs 64k. That with an interleave of 9 and 1 KB sectors (sic!). I have since optimized the data transfer routines by writing them in assembly language. This should probably allow interleaves in the range 1-3. I have not yet been able to test any other interleaves, as I have not wanted to reformat the entire disk (it takes quite a while to copy 300 megabytes to floppies and back...) Note that when formatting the disk, it can be helpful to explicitly specify that mkfs does no interleaving on the file system level as that is already handled by the drive. As a reference, measured the same way my 40ms 42MB MFM drive gives 40 kB/sec (sic!). I was not able to improve it from that. The scsi disk was actually so much faster that I copied /bin and /usr/bin to the scsi disk (/u/bin & /u/usr/bin) and put those in PATH before /bin and /usr/bin. The difference is very significant. The biggest problem with the driver is that during heavy disk activity the serial lines lose incoming characters. But then I hear this is a general problem with Microport... BTW, my driver cannot be used to boot from the scsi disk. I use the 42 MB disk that came with the system for booting and swap (luckily I have 10 MB of ram, so the machine hardly ever swaps). Tatu Ylonen ylo@sauna.hut.fi ----------------------------- From: George Robbins Subject: Re: Using the uucp daemon (TCP/IP) on System V.3 with TCP/IP Date: 9 Jul 89 17:34:01 GMT Keywords: UUCP TCP/IP uucpd uucico sockets BSD4.3 SysV.3 To: unix-wizards@sem.brl.mil In article <3674@ursa-major.SPDCC.COM> cspencer@ursa-major.spdcc.COM (Cliff Spencer) writes: > >>Porting BSD 4.3 UUCP daemon has already been done several times for different > >>incarnations of TCP/IP implementations for system V Unix's. Unfortunately > >>none of them are "free" that I know of. > >I only need the patches, I have the BSD4.3 uucpd source... > > What's the big mystery? Doesn't the daemon just spawn /usr/lib/uucp/uucico? Well, yes and no. It plays with sockets doing a listen and opening a a connection and then simulates a login and finally runs uucico passing the open sockets as stdin/stdout. If you have a completely functional socket-emulation package, it shouldn't be a big deal. Also, your uucp is expected to know that it shouldn't try to do all those terminal oriented ioctls on sockets... -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite) ----------------------------- End of UNIX-WIZARDS Digest ************************** ---------- end of forwarded message