Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!cmcl2!brl-adm!adm!Postmaster%TRINCC.BITNET@mitvma.mit.edu From: Postmaster%TRINCC.BITNET@mitvma.mit.edu (PMDF Mail Server) Newsgroups: comp.unix.questions Subject: Undeliverable mail Message-ID: <16441@brl-adm.ARPA> Date: 9 Jul 88 07:25:06 GMT Sender: news@brl-adm.ARPA Lines: 1146 The message could not be delivered to: Addressee: TRIN4 Reason: %MAIL-E-SYNTAX, error parsing 'DJA1::[TRIN4.BOX1024]' ---------------------------------------- Received: from JNET-DAEMON by TRINCC.BITNET; Mon, 4 Jul 88 04:06 EST Received: From YALEVM(MAILER) by TRINCC with Jnet id 4462 for TRIN4@TRINCC; Mon, 4 Jul 88 04:04 EST Received: by YALEVM (Mailer X1.24) id 4459; Mon, 04 Jul 88 04:01:18 EST Date: Wed, 29 Jun 88 02:45:52 EST From: Mike Muuss The Moderator Subject: INFO-UNIX Digest V5#083 Sender: Info-Unix distribution list To: Robert Cummings Reply-to: INFO-UNIX@BRL.ARPA Comments: To: INFO-UNIX@BRL.ARPA INFO-UNIX Digest Wed, 29 Jun 1988 V5#083 Today's Topics: Re: Bliss Compiler wanted Re: bbs for unix based systems Re: Real-time UNIX - what is it & who has it? Recommendations wanted for workstations and CASE tools Re: "cd path" strangeness Re: RCS and SCCS Re: HOW DO I MAKE VI'S AUTOINDENT NOT USE TABS? Shouting the return code. (Re: Meaning of "rc" in cron/log) Re: how can I "." in csh? Re: Shouting the return code. (Re: Meaning of "rc" in cron/log) Re: Is a NEED for more COMMERCIAL usenet feed providers? Re: AT&T vs. CSS (PC/Tools) Tabs in VI SLIP protocol specification Termcap/Terminfo question UUCP Over TCP/IP Re: RCS and SCCS (and CMS) Getting vi to automagically use macros ----------------------------------------------------------------- From: Steve Simmons Subject: Re: Bliss Compiler wanted Date: 24 Jun 88 14:36:01 GMT To: info-unix@brl-sem.arpa In article <315@gt-eedsp.UUCP> jensen@gt-eedsp.UUCP (P. Allen Jensen) writes: > >Is the CMU Bliss the same as the BLISS used by DEC ? In '83 I was supporting some BLISS-10 utilities at ADP Network Services. We ran into bugs in the DEC BLISS-10 compiler which DEC wouldn't fix. We had source, which was full of CMU names. I went to CM to see if theirs was PD, and if so, could we get it. On doing some comparison, we found that the DEC BLISS-10 compiler was absolutely identical to the CMU except for a few bug fixes CMU had done since DEC picked it up. About this time DEC came out with the BLISS-16, BLISS-32, and BLISS-36 compilers to be their "standard systems development language". They wanted a ludicrous amount of money for BLISS-36. We ordered an evaluation copy, and found it was absolutely identical to BLISS-10. Same checksum. And same support categore. I forget the name, but it meant "We will accept bug reports. But we will take no action." That's the way it was in '83. Needless to say, we didn't buy BLISS-36. If you can get BLISS from CMU and you have a PDP-10 machine, do it. -- +- Steve Simmons UNIX Systems Mgr. Schlumberger CAD/CAM -+ + simmons@applga.uucp ...umix!applga!simmons + +- "Opinions expressed are all my own, etc, etc, etc, etc, etc, etc, etc." -+ ----------------------------- From: Karl Meiser Subject: Re: bbs for unix based systems Date: 24 Jun 88 19:41:55 GMT To: info-unix@brl-sem.arpa I myself should be suggesting my own work, premature as it is. Currently i am working on a message system (run from the shell) but it is no where near complete. I will however suggest AKCS. Infact, the system i am currently at is the home of AKCS. This software has linking prgs, etc, so that you can connect systems together by sending new items back and forth. This system currently connects 4 systems, and the more the better. For more information, contact Karl Denniger at (312)566-8909 voice, (312)566-8911 or (312)566-8912 for the system. You can also send mail to ..!ddsw1!karl -- Karl Meiser ..!att!spl1!ddsw1!koala I said that?? I musta been sleeping! ----------------------------- From: Ian Kluft Subject: Re: Real-time UNIX - what is it & who has it? Date: 24 Jun 88 20:34:30 GMT To: info-unix@SEM.BRL.MIL / adamm@necis.UUCP (Adam Moskowitz) / writes: > A friend of mine has asked to help him locate a "real-time UN*X or UN*X-like > operating system". [ ... ] > Assuming that you are doing something like data acquisition or > process control, what is required to make an O/S "real-time"? > > The answer he and I came up with was this: the ability to have absolute > control over the scheduling of processes. Two issues to note when looking for a real-time OS are kernel pre-emption context switching time Kernel pre-emption is an important one to consider on Unix because most Unix systems do not allow system calls to be interrupted. Of course, context-switching time is somewhat obvious because it affects the time between arrival of an interrupt and (re)starting a user process to handle the event. That's really what it comes down to. If a guarantee can be made of the amount of time it takes between an event and entering the code to handle it, an OS is considered real-time. Of course, if that time is too long, it isn't worth mentioning. [End of unbiased material] While everyone was mentioning the real-time Unix's they knew of, I thought I'd mention the one I work with. Hewlett-Packard's HP-UX is a full System V with extentions for BSD 4.2 and real-time. While I don't have the exact numbers for measured real-time response, I remember that they are measured in milliseconds, as would be expected. ------------------------------------------------------------ Ian Kluft RAS Lab hplabs!hprasor!kluft HP Network Systems Group kluft@hpda.hp.com Cupertino, CA ------------------------------------------------------------ ----------------------------- From: John Coughlin Subject: Recommendations wanted for workstations and CASE tools Date: 25 Jun 88 16:20:27 GMT To: info-unix@SEM.BRL.MIL Our company will soon be purchasing a number of workstations for use in software development with CASE tools. We are currently considering Apollo or Sun machines and I would appreciate any recommendations. ---------------------------------------------------------------------- Paul Burry UUCP: sce!jc Dy4 Systems Inc. PHONE: (613)-596-9911 21 Credit Union Way, Nepean, Ontario Canada K2H 9G1 ---------------------------------------------------------------------- ----------------------------- From: Geoff Rimmer Subject: Re: "cd path" strangeness Date: 26 Jun 88 22:31:54 GMT Sender: news@warwick.uucp Keywords: csh cd xenix sysv To: info-unix@brl-sem.arpa In article <922@.UUCP> jbush@ficc.UUCP (james bush) writes: >In article <337@vector.UUCP>, chip@vector.UUCP (Chip Rosenthal) writes: >> Here is a wierd one. In csh, move to some directory which doesn't have >> a "path" subdirectory. Then type either "cd path" or "chdir path". >> >> The expected response would be "path: No such file or directory." Instead, >> no message is issued, and either you stay where you were or you move to >> $path[1]... > >This is even more wierd. I tried it on our Intel Xenix system, and it worked >as you said when I did it under my login. However, when I tried to show it >to my friend under his id, it came up with the "expected" error message! I >am not sure what the difference is. Perhaps he uses Bourne shell? extravagent_prompt % sh $ cd path path: bad directory $ No flames please - term finishes in under a week - so I won't be here to read them 8-) Geoff. >James Bush, Ferranti, Houston Praise the Lord >Internal address: jbush extension 5230, mail stop A/3204, room A/3602 >External address: ..!uunet!nuchat!sugar!ficc!jbush ----------------------------------------------------------------- Geoff Rimmer, Computer Science, Warwick University, UK. maujd@uk.ac.warwick.opal "I do SMILE humour - people aren't SUPPOSED to laugh." "Yeah, but they aren't supposed to throw heavy objects and shout 'Get off you boring bastard, we've heard better jokes on the speaking clock!'" - Filthy Rich and Catflap (BBC TV) (Get your local TV station to buy this excellent comedy series!!) ----------------------------------------------------------------- ----------------------------- From: Joel Clark Subject: Re: RCS and SCCS Date: 27 Jun 88 17:28:47 GMT To: info-unix@brl-sem.arpa In article <661@pyuxe.UUCP> mayerar@pyuxe.UUCP (80132-A Mayer) writes: >In article <710@ubu.warwick.UUCP> maujd@warwick.UUCP (Geoff Rimmer) writes: >>Which out of RCS and SCCS do people prefer? >> >>Geoff. > >One good point of RCS is that it stores the most recent version and >uses deltas to get back to the previous versions. SCCS stores the >original version and uses deltas to get to the most recent version. > > Andrew J. Mayer > BELLCORE > >{ariel,burl,clyde,floyd,gamma,harpo,ihnp4,mhuxl,rutgers}!pyuxe!mayerar Even though I have written software with similar functionality as SCCS, I have never understood this argument about storing the most recent version as opposed to storing the original version. For example given the following actual SCCS file: I 1 /* * module control port settings */ D 2 #define NPGM_DONE 0x01 E 2 I 2 #define RRCV 0x02 E 2 #define RLSRCV 0x02 #define NPROGRAM 0x80 E 1 We see the original and the most recent stored in the same manor, line by line. Any program trying to a extract version still has to look at every line to decide if that line is in the desired version or not. Can anyone explain to me how a program could store `the most recent version` such that each line in the file does not need to be examined to determine if it is in the most recent version? Joel Clark Intel Scientific Computers joel@intelisc.uucp.com Beaverton, OR {tektronix}!ogcvax!intelisc!joel (503) 629 7732 ----------------------------- From: "David I. Berg" Subject: Re: RCS and SCCS Date: 28 Jun 88 16:14:24 GMT To: info-unix@brl-sem.arpa In article <710@ubu.warwick.UUCP>, maujd@warwick.UUCP (Geoff Rimmer) writes: > Which out of RCS and SCCS do people prefer? .......... > ..... What are the good and bad points of each system? > I have used both systems, depending on which was available on the particular computer I was using. I find RCS particularly easier to use than SCCS. In fact, in one case, I converted all my SCCS files to RCS using the sccstorcs utility. Another feature of RCS is that it stores the current version of your file and the changes backward to the original, whereas SCCS stores the original version of your file and the changes forward to the current. Therefore, it will take SCCS a trifle longer to produce the current version than RCS. ----------------------------- From: Eduardo Krell Subject: Re: RCS and SCCS Date: 28 Jun 88 19:22:01 GMT Sender: netnews@ulysses.homer.nj.att.com To: info-unix@SEM.BRL.MIL In article <290@intelisc.UUCP> joel@intelisc.UUCP (Joel Clark) writes: >Can anyone explain to me how a program could store `the most recent version` >such that each line in the file does not need to be examined to determine >if it is in the most recent version? You store the most recent version at the beginning of the file in clear text followed by the reverse delta to get the previous version (followed by the reverse delta to get the version before that, etc.). Time to get the latest version is thus proportional only to the size of that version. Time to get version N is proportional to the size of the last version plus the size of all deltas necessary to get from there down to version N. Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ UUCP: {ihnp4,ucbvax}!ulysses!ekrell ARPA: ekrell@ulysses.att.com ----------------------------- From: Richard Harter Subject: Re: RCS and SCCS Date: 28 Jun 88 20:08:42 GMT To: info-unix@SEM.BRL.MIL In article <290@intelisc.UUCP> joel@intelisc.UUCP (Joel Clark) writes: >Can anyone explain to me how a program could store `the most recent version` >such that each line in the file does not need to be examined to determine >if it is in the most recent version? There are two different ways that I know of to do this. One is the way RCS does it. When the file is updated the delta is calculated in terms of carrying the latest version to the previous version. The delta is appended to the stored deltas, and the previous version is replaced by the updated version. I can't give you the details on the other way (it is proprietary to ADC) but the essence of the matter is the information about the lines do not have to be stored with the lines. -- In the fields of Hell where the grass grows high Are the graves of dreams allowed to die. Richard Harter, SMDS Inc. ----------------------------- From: Joe Bob Willie Subject: Re: RCS and SCCS Date: 28 Jun 88 21:46:14 GMT To: info-unix@brl-sem.arpa In article <29975@cca.CCA.COM>, g-rh@cca.CCA.COM (Richard Harter) writes: > It is true, however, that there is, in principle, a signifigant performance > advantage for the RCS scheme versus the SCCS scheme. SCCS must process > all lines including those not currently active; RCS need only process those > that are currently active. Furthermore RCS does not need to do any processing > on the line other than copying it out; SCCS has to check the control data > for the line. On the other hand, RCS pays a penalty if the version being > extracted is not the latest. > -- > Richard Harter, SMDS Inc. [ In the Oil Fields of HELL, Where the drought grows long and HOT ] OK - I'll bite, and I'm sure others will also. What exactly does an RCS file look like. I'm a die-hard SCCS junkie. How about a few specific examples for those of us without RCS or RCS documentation. - John. -- The Beach Bum Big "D" Home for Wayward Hackers UUCP: ...!killer!rpp386!jfh jfh@rpp386.uucp :SMAILERS "You are in a twisty little maze of UUCP connections, all alike" -- fortune ----------------------------- From: Clark Morgan Subject: Re: HOW DO I MAKE VI'S AUTOINDENT NOT USE TABS? Date: 28 Jun 88 07:53:13 GMT To: info-unix@SEM.BRL.MIL ?In article <1219@bakerst.UUCP> kathy@bakerst.UUCP (Kathy Vincent) writes: >In article <2965@tekig4.TEK.COM> clarkm@tekig4.UUCP I whine: > > ....about Vi putting tabs in my files.... > ?I'm coming in late to this discussion, so if I missed something, ?well, sorry. ? ?But there *is* an option that says not to auto-tab. ? ?I use vi all the time - using SVR2 and SVR3 on 3B20s, and using ?3.5 UNIX on my on my UNIX PC. I never get any tabs I don't explicitly ?ask for. ? ?I did a ? ? :se all ? ?to check the settings I have when I'm working, and included in the ?list is one ? ? noautoindent ? ?That must be the default on all the systems I work on because I don't ?ever set up anything. .... ? ?Kathy Vincent ------> {ihnp4|att|codas|pacbell}!bakerst!kathy ? ------> { favourite AT&T gateway }!wruxh!unix ==================================================================== Um Kathy, I want autoindent + NO TABS (for C programs and the like). ==================================================================== -- Clark Morgan, Tektronix Lab Instruments Engineering (503) 627-3545 clarkm@tekig4.LEN.TEK.COM | {...,decvax,uw-beaver}!tektronix!tekig4!clarkm US Mail: Tektronix, P.O. Box 500, DS 39-087, Beaverton, OR 97077 ----------------------------- From: Felix Lee Subject: Shouting the return code. (Re: Meaning of "rc" in cron/log) Date: 28 Jun 88 11:08:37 GMT Sender: news@psuvax1.cs.psu.edu To: info-unix@SEM.BRL.MIL Does ksh let you put the return code in the prompt? Something like PS1='($?) '? Showing only non-zero return codes would be better. Return codes are interesting. Really. IBM's VM/CMS will tell you about non-zero return codes. (The prompt is either 'R;' or 'R(nnn);') Unix hides return codes well. Ever try unconfusing someone about why "true" is "exit 0", but "false" is "exit 1"? Maybe if the shell shouted the return code, more programs would return interesting codes. (lament) Where are the return codes for fsck documented? Why does "strings" return -40? Why does "od" return 10? -- Felix Lee flee@gondor.cs.psu.edu *!psuvax1!gondor!flee ----------------------------- From: "Wolf N. Paul" Subject: Re: how can I "." in csh? Date: 28 Jun 88 12:32:45 GMT To: info-unix@brl-sem.arpa In article <3513@ncrcae.Columbia.NCR.COM> rogerc@ncrcae.Columbia.NCR.COM (Roger Collins) writes: >In csh, is there an easy way to duplicate the function of Bourne's "." >command? I want to input commands from a file and have them >change the current layer's environment. The csh command you want is called "source". Thus, "source .login" is roughly equivalent to the Bourne/Korn shell command ". .profile". -- Wolf N. Paul * 3387 Sam Rayburn Run * Carrollton TX 75007 * (214) 306-9101 UUCP: killer!dcs!wnp ESL: 62832882 DOMAIN: wnp@dcs.UUCP TLX: 910-380-0585 EES PLANO UD ----------------------------- From: Bob Mende Pie Subject: Re: how can I "." in csh? Date: 28 Jun 88 14:03:12 GMT To: info-unix@SEM.BRL.MIL In article <3513@ncrcae.Columbia.NCR.COM> rogerc@ncrcae.Columbia.NCR.COM (Roger Collins) writes: > In csh, is there an easy way to duplicate the function of Bourne's "." > command? I want to input commands from a file and have them > change the current layer's environment. The command you want is source. /Bob... -- {...}!rutgers!mende mende@aramis.rutgers.edu mende@zodiac.bitnet YOU can't talk, your SHIRT is BROKEN. ----------------------------- From: Lloyd Zusman Subject: Re: how can I "." in csh? Date: 28 Jun 88 20:05:42 GMT To: info-unix@brl-sem.arpa In article <129@dcs.UUCP> wnp@dcs.UUCP (Wolf N. Paul) writes: In article <3513@ncrcae.Columbia.NCR.COM> rogerc@ncrcae.Columbia.NCR.COM (Roger Collins) writes: >In csh, is there an easy way to duplicate the function of Bourne's "." >command? ... The csh command you want is called "source". Thus, "source .login" is roughly equivalent to the Bourne/Korn shell command ". .profile". ... and you can even get a bona fide "." command in csh by means of an alias: alias . source ... would do the trick. You'd probably want to put this in your .cshrc file. -- Lloyd Zusman UUCP: ...!ames!fxgrp!ljz Master Byte Software Internet: ljz%fx.com@ames.arc.nasa.gov Los Gatos, California or try: fxgrp!ljz@ames.arc.nasa.gov "We take things well in hand." ----------------------------- From: "Lawrence V. Cipriani" Subject: Re: Shouting the return code. (Re: Meaning of "rc" in cron/log) Date: 28 Jun 88 14:46:42 GMT To: info-unix@SEM.BRL.MIL In article <3671@psuvax1.cs.psu.edu>, flee@gondor.cs.psu.edu (Felix Lee) writes: > Does ksh let you put the return code in the prompt? Something like > PS1='($?) '? Yes, this PS1 displays the exit value of the "previous command". $? will change value on an interrupt however. > Showing only non-zero return codes would be better. Why? Knowing a command completed successfully might be useful if stdout/stderr for the command were redirected. > Return codes are interesting. Really. IBM's VM/CMS will tell you about > non-zero return codes. (The prompt is either 'R;' or 'R(nnn);') Return codes are boring. Really. > Unix hides return codes well. If you need them you can get them, if you don't want to see them you don't have to. I bet you don't have this flexibility in IBM's VM/CMS. My feeling is the shorter my PS1 prompt the better. There was a time when my PS1 included my login id, the machine name I was logged in on, the time of day (you can do this in ksh), and even some graphics sequences. After a few weeks I changed it all back to just the machine name (since I will simultaneously be logged in several systems). >Ever try unconfusing someone about why > "true" is "exit 0", but "false" is "exit 1"? Yeah, and read the man page for true/false to them, it always gets funny looks, and usually some laughs after you explain it to them. ... > Felix Lee flee@gondor.cs.psu.edu *!psuvax1!gondor!flee -- Larry Cipriani, AT&T Network Systems and Ohio State University Domain: lvc@tut.cis.ohio-state.edu Path: ...!cbosgd!osu-cis!tut.cis.ohio-state.edu!lvc (strange but true) ----------------------------- From: "William E. Davidsen Jr" Subject: Re: Is a NEED for more COMMERCIAL usenet feed providers? Date: 28 Jun 88 16:44:39 GMT To: info-unix@SEM.BRL.MIL In article <317@ditka.UUCP> kls@ditka.UUCP (Karl Swartz) writes: | Greg, I know this isn't exactly what you had in mind, but what about | a west coast uunet? While helping a (non-local) friend look into | news feed options, I realized that uunet costs a *lot* more for west | coast folks than those who are closer. This is based on a TrailBlazer For low budget sites, uunet can be reached by PC Pursuit and Dial America service. This keeps the cost way down. If you need to send stuff during the day, of course, you will still be faced with a stiff bill. If you are looking for a local feed, rather than the gateway features uunet provides, you should be able to find one almost anywhere. I think portal will feed anyone on the west coast for a price, but I have no idea what that price is. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me ----------------------------- From: Keith Ericson Subject: Re: AT&T vs. CSS (PC/Tools) Date: 28 Jun 88 18:46:18 GMT Keywords: AT&T, lawsuit, CSS, PC/Tools, PC/VI To: info-unix@SEM.BRL.MIL In article <142@wash08.UUCP> txr98@wash08.UUCP (Timothy Reed) writes: >A friend at ATT told me last year that ATT owned more than afew copies >of the MKS toolkit on DOS PCs at most of their sites in Jersey. If MKS >didn't license unix from ATT, would that be considered tacit approval? > Never assume that any one part of a large organization even knows, much less approves, of what another department, section, group or whatever is doing. keith ----------------------------- From: The Silent Killer Subject: Tabs in VI Date: 28 Jun 88 19:01:17 GMT To: info-unix@brl-sem.arpa > ==================================================================== > Um Kathy, I want autoindent + NO TABS (for C programs and the like). > ==================================================================== The way I do it is by using the unix utility 'expand' from within 'VI'. I know this does not prevent insertion of tabs, but it at least removes them once you have used the command !expand The may be (, {, 1G etc. In writing LISP functions, for example, I find the command '!%expand' very useful. Anant Patkar. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ o __________________ ____________________________ / ) | | ___| | | | _| __|_ / | patkar@ecn.purdue.edu ---| o--| ( | `___| | ' '__| ) o/ | patkar@purche.BITNET \_) | | \ | | | `-- | \ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ----------------------------- From: Lyndon Nerenberg Subject: SLIP protocol specification Date: 28 Jun 88 20:11:23 GMT To: info-unix@SEM.BRL.MIL Lately there have been a number of requests for a description of the SLIP encapsulation scheme for sending IP packets over serial links. SRI has (finally :-) issued an RFC describing how this is currently implemented. It's only six pages long, so I've attached a copy. Apologies if you've already seen this. (cut the .signature at the end) --lyndon VE6BBM -----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<----- Network Working Group J. Romkey Request for Comments: 1055 June l988 A NONSTANDARD FOR TRANSMISSION OF IP DATAGRAMS OVER SERIAL LINES: SLIP INTRODUCTION The TCP/IP protocol family runs over a variety of network media: IEEE 802.3 (ethernet) and 802.5 (token ring) LAN's, X.25 lines, satellite links, and serial lines. There are standard encapsulations for IP packets defined for many of these networks, but there is no standard for serial lines. SLIP, Serial Line IP, is a currently a de facto standard, commonly used for point-to-point serial connections running TCP/IP. It is not an Internet standard. Distribution of this memo is unlimited. HISTORY SLIP has its origins in the 3COM UNET TCP/IP implementation from the early 1980's. It is merely a packet framing protocol: SLIP defines a sequence of characters that frame IP packets on a serial line, and nothing more. It provides no addressing, packet type identification, error detection/correction or compression mechanisms. Because the protocol does so little, though, it is usually very easy to implement. Around 1984, Rick Adams implemented SLIP for 4.2 Berkeley Unix and Sun Microsystems workstations and released it to the world. It quickly caught on as an easy reliable way to connect TCP/IP hosts and routers with serial lines. SLIP is commonly used on dedicated serial links and sometimes for dialup purposes, and is usually used with line speeds between 1200bps and 19.2Kbps. It is useful for allowing mixes of hosts and routers to communicate with one another (host-host, host-router and router- router are all common SLIP network configurations). AVAILABILITY SLIP is available for most Berkeley UNIX-based systems. It is included in the standard 4.3BSD release from Berkeley. SLIP is available for Ultrix, Sun UNIX and most other Berkeley-derived UNIX systems. Some terminal concentrators and IBM PC implementations also support it. SLIP for Berkeley UNIX is available via anonymous FTP from uunet.uu.net in pub/sl.shar.Z. Be sure to transfer the file in binary mode and then run it through the UNIX uncompress program. Take Romkey [Page 1] RFC 1055 Serial Line IP June 1988 the resulting file and use it as a shell script for the UNIX /bin/sh (for instance, /bin/sh sl.shar). PROTOCOL The SLIP protocol defines two special characters: END and ESC. END is octal 300 (decimal 192) and ESC is octal 333 (decimal 219) not to be confused with the ASCII ESCape character; for the purposes of this discussion, ESC will indicate the SLIP ESC character. To send a packet, a SLIP host simply starts sending the data in the packet. If a data byte is the same code as END character, a two byte sequence of ESC and octal 334 (decimal 220) is sent instead. If it the same as an ESC character, an two byte sequence of ESC and octal 335 (decimal 221) is sent instead. When the last byte in the packet has been sent, an END character is then transmitted. Phil Karn suggests a simple change to the algorithm, which is to begin as well as end packets with an END character. This will flush any erroneous bytes which have been caused by line noise. In the normal case, the receiver will simply see two back-to-back END characters, which will generate a bad IP packet. If the SLIP implementation does not throw away the zero-length IP packet, the IP implementation certainly will. If there was line noise, the data received due to it will be discarded without affecting the following packet. Because there is no 'standard' SLIP specification, there is no real defined maximum packet size for SLIP. It is probably best to accept the maximum packet size used by the Berkeley UNIX SLIP drivers: 1006 bytes including the IP and transport protocol headers (not including the framing characters). Therefore any new SLIP implementations should be prepared to accept 1006 byte datagrams and should not send more than 1006 bytes in a datagram. DEFICIENCIES There are several features that many users would like SLIP to provide which it doesn't. In all fairness, SLIP is just a very simple protocol designed quite a long time ago when these problems were not really important issues. The following are commonly perceived shortcomings in the existing SLIP protocol: - addressing: both computers in a SLIP link need to know each other's IP addresses for routing purposes. Also, when using SLIP for hosts to dial-up a router, the addressing scheme may be quite dynamic and the router may need to inform the dialing host of Romkey [Page 2] RFC 1055 Serial Line IP June 1988 the host's IP address. SLIP currently provides no mechanism for hosts to communicate addressing information over a SLIP connection. - type identification: SLIP has no type field. Thus, only one protocol can be run over a SLIP connection, so in a configuration of two DEC computers running both TCP/IP and DECnet, there is no hope of having TCP/IP and DECnet share one serial line between them while using SLIP. While SLIP is "Serial Line IP", if a serial line connects two multi-protocol computers, those computers should be able to use more than one protocol over the line. - error detection/correction: noisy phone lines will corrupt packets in transit. Because the line speed is probably quite low (likely 2400 baud), retransmitting a packet is very expensive. Error detection is not absolutely necessary at the SLIP level because any IP application should detect damaged packets (IP header and UDP and TCP checksums should suffice), although some common applications like NFS usually ignore the checksum and depend on the network media to detect damaged packets. Because it takes so long to retransmit a packet which was corrupted by line noise, it would be efficient if SLIP could provide some sort of simple error correction mechanism of its own. - compression: because dial-in lines are so slow (usually 2400bps), packet compression would cause large improvements in packet throughput. Usually, streams of packets in a single TCP connection have few changed fields in the IP and TCP headers, so a simple compression algorithms might just send the changed parts of the headers instead of the complete headers. Some work is being done by various groups to design and implement a successor to SLIP which will address some or all of these problems. Romkey [Page 3] RFC 1055 Serial Line IP June 1988 SLIP DRIVERS The following C language functions send and receive SLIP packets. They depend on two functions, send_char() and recv_char(), which send and receive a single character over the serial line. /* SLIP special character codes */ #define END 0300 /* indicates end of packet */ #define ESC 0333 /* indicates byte stuffing */ #define ESC_END 0334 /* ESC ESC_END means END data byte */ #define ESC_ESC 0335 /* ESC ESC_ESC means ESC data byte */ /* SEND_PACKET: sends a packet of length "len", starting at * location "p". */ void send_packet(p, len) char *p; int len; { /* send an initial END character to flush out any data that may * have accumulated in the receiver due to line noise */ send_char(END); /* for each byte in the packet, send the appropriate character * sequence */ while(len--) { switch(*p) { /* if it's the same code as an END character, we send a * special two character code so as not to make the * receiver think we sent an END */ case END: send_char(ESC); send_char(ESC_END); break; /* if it's the same code as an ESC character, * we send a special two character code so as not * to make the receiver think we sent an ESC */ case ESC: send_char(ESC); send_char(ESC_ESC); break; Romkey [Page 4] RFC 1055 Serial Line IP June 1988 /* otherwise, we just send the character */ default: send_char(*p); } p++; } /* tell the receiver that we're done sending the packet */ send_char(END); } /* RECV_PACKET: receives a packet into the buffer located at "p". * If more than len bytes are received, the packet will * be truncated. * Returns the number of bytes stored in the buffer. */ int recv_packet(p, len) char *p; int len; { char c; int received = 0; /* sit in a loop reading bytes until we put together * a whole packet. * Make sure not to copy them into the packet if we * run out of room. */ while(1) { /* get a character to process */ c = recv_char(); /* handle bytestuffing if necessary */ switch(c) { /* if it's an END character then we're done with * the packet */ case END: /* a minor optimization: if there is no * data in the packet, ignore it. This is * meant to avoid bothering IP with all * the empty packets generated by the * duplicate END characters which are in Romkey [Page 5] RFC 1055 Serial Line IP June 1988 * turn sent to try to detect line noise. */ if(received) return received; else break; /* if it's the same code as an ESC character, wait * and get another character and then figure out * what to store in the packet based on that. */ case ESC: c = recv_char(); /* if "c" is not one of these two, then we * have a protocol violation. The best bet * seems to be to leave the byte alone and * just stuff it into the packet */ switch(c) { case ESC_END: c = END; break; case ESC_ESC: c = ESC; break; } /* here we fall into the default handler and let * it store the character for us */ default: if(received < len) p[received++] = c; } } } Romkey [Page 6] -- {alberta,pyramid,uunet}!ncc!lyndon lyndon@Nexus.CA ----------------------------- From: ok@quintus Subject: Termcap/Terminfo question Date: 28 Jun 88 20:48:27 GMT Sender: news@quintus.uucp To: info-unix@brl-sem.arpa When should a program use the 'is' (initialisation string) or 'if' (initialisation file) capabilities? I have a program which sends this string when it starts, but a number of VT100 emulators adapt to window size by adding appropriate co#COLS and li#ROWS information, but leave is: setting the scrolling region to 24 lines, which seems unhelpful. There seem to be three sets of strings a program might send at start and finish: is/rs initialisation string / reset string [is1..is3/rs1..rs3 in terminfo; also if/rf] vs/ve "visual" start / "visual" end ti/te said to be meant for things that use cm (cursor motion) Exactly when should these things be used? Is there a book which explains in clear and simple language what each of the capabilities means, how to decide what to set it to, and when to use it? [I have the 5R3 manuals. I need an idiot's guide.] ----------------------------- From: "M. D. Parker" Subject: UUCP Over TCP/IP Date: 28 Jun 88 20:52:12 GMT Keywords: uucp, uucpd, bsd4.3 To: info-unix@brl-sem.arpa In bits of the BSD documentation, there is a mention of the TCP/IP UUCP server deamon (i.e. /etc/uucpd). My question is if you are the sending party, how do you tell the system to use the UUCP protocol? I find nothing in this in connection with the L.sys file, in fact, I have really found nothing at all. Can anybody enlighten me on /etc/uucpd and its operation, invokation, etc.? Thanks.... ----------------------------- From: Doug Landauer Subject: Re: RCS and SCCS (and CMS) Date: 28 Jun 88 21:25:47 GMT Sender: news@sun.uucp Keywords: CMS RCS SCCS To: info-unix@brl-sem.arpa In article <1134@cod.NOSC.MIL>, dberg@cod.NOSC.MIL (David I. Berg) wrote: > Another feature of RCS is that it stores the current > version of your file and the changes backward to the original, whereas > SCCS stores the original version of your file and the changes forward > to the current. This is a common misconception (oversimplification) -- it implies that it could take significantly longer using SCCS to get the current version of the file than for it to get the original version. In fact, SCCS does not store separate deltas; it stores all of the deltas together, in the appropriate places within "the original file", in the file in such a way that it takes about the same amount of time to get any version. There are several barely relevant performance implications of the differences between this scheme and what RCS does: + for RCS: For retrieving the latest version (RCS is betting that this is the most common case), RCS is likely to be faster; ~ : For retrieving any other versions, RCS slows down relative to its own performance on the latest version (and at some point depending on how many deltas as well as how many lines changed per delta, it may be slower than SCCS); + for SCCS: Doing RCS check-ins (storing new versions) should be distinctly slower than doing SCCS deltas; > I find RCS particularly easier to use than SCCS. I personally agree with this statement (disclaimer: Sun doesn't officially agree). The BSD "sccs" front-end command helps some. Finally, the performance differences mentioned above probably add up (over the course of my entire SCCS career) to less time than I spent composing this message (as David I. Berg put it, "it will take SCCS a trifle longer"), so the ease-of-use factor should become the overriding factor if you're starting a new project in a new company or on your own. In practice, the "what-they-use-here" factor is the real overriding factor. This is one of the few areas where VMS (gasp!) really does do better than Unix (IMHO) -- DEC's CMS (though it has brain damage in some ways) really does have some features that would make it, on the whole, better than either SCCS or RCS, if you could use it on Unix instead of VMS. -- Doug Landauer Sun Microsystems, Inc. ARPA Internet: landauer@sun.com Software Products Division UUCP: ...!sun!landauer -- Acronym glossary: (Some of these are trademarks -- you know who you are.) BSD -- Berkeley Software Distribution CMS -- Code Management System (I think) DEC -- Digital Equipment Corporation IMHO -- In My Humble Opinion RCS -- Revision Control System SCCS -- Source Code Control System UUCP -- Unix-to-Unix CoPy VMS -- Virtual Memory System (an operating system for some DEC computers) -- ----------------------------- From: Adam Moskowitz Subject: Getting vi to automagically use macros Date: 28 Jun 88 23:01:19 GMT Keywords: vi, macros To: info-unix@SEM.BRL.MIL This has probably been asked before, but since limited disk space prevents me from saving everything I might ever need . . . Is there a way to set up some vi macros via my .exrc file or the EXINIT environment variable? I know that I can fake it my mapping the two-char sequence "@x" to the string I want, but is there a way to automatically have a "real" macro set up every time I start-up vi? E-MAIL me your replies and I'll summarize to the net if I get anything. Thanx in advance. -- Adam S. Moskowitz ...!(backbone)!{necntc,encore}!necis!adamm "The morning blues, they make me feel so bad; it's the worst damn feeling I ever had." ----------------------------- End of INFO-UNIX Digest ***********************