Article 4510 of alt.sys.pdp10: Path: news3.best.com!news1.best.com!su-news-hub1.bbnplanet.com!news.gtei.net!newsfeed.berkeley.edu!news.u.washington.edu!Tomobiki-Cho.CAC.Washington.EDU!mrc From: Mark Crispin Newsgroups: alt.sys.pdp10 Subject: Re: Text files with line numbers Date: Fri, 11 Dec 1998 17:29:17 -0800 Organization: Networks & Distributed Computing Lines: 33 Message-ID: References: <74rkug$fa6@nnrp2.farm.idt.net> <74s2r0$183$1@agate.berkeley.edu> NNTP-Posting-Host: tomobiki-cho.cac.washington.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: nntp1.u.washington.edu 913426164 32398 (None) 140.142.17.38 X-Complaints-To: help@cac.washington.edu NNTP-Posting-User: dak To: Brian Harvey In-Reply-To: <74s2r0$183$1@agate.berkeley.edu> Xref: news3.best.com alt.sys.pdp10:4510 On 11 Dec 1998, Brian Harvey wrote: > Each program still had to be written to check for the bit; there wasn't any > kernel magic to hide the SOS line number words, or anything like that. That was the case on TOPS-10 and WAITS, but I can assure you that on TOPS-20, the kernel hid the SOS line number words for files open in 7-bit unless you set the OP%PLN bit. In other words: MOVE 1,JFN MOVX 2,<!OF%RD OPENF% ERJMP LOSE HRROI 2,BUF MOVX 3,-5 SIN% would give you the first five real bytes of an SOS file in BUF, whereas: MOVE 1,JFN MOVX 2,<!OF%RD!OF%PLN OPENF% ERJMP LOSE HRROI 2,BUF MOVX 3,-5 SIN% would give you the line number. -- Mark -- * RCW 19.149 notice: This email address is located in Washington State. * * Unsolicited commercial email may be billed $500 per message. * Science does not emerge from voting, party politics, or public debate. Article 4513 of alt.sys.pdp10: Path: news3.best.com!news2.best.com!feed1.news.rcn.net!rcn!news.ultranet.com!not-for-mail From: "Alan H. Martin" Newsgroups: alt.sys.pdp10 Subject: Re: Text files with line numbers Date: Sat, 12 Dec 1998 13:35:27 -0500 Organization: UltraNet Communications , an RCN Company http://www.ultranet.com/ Lines: 48 Message-ID: <3672B76F.9ECB5043@MA.UltraNet.Com> References: NNTP-Posting-Host: d191.dial-6.cmb.ma.ultra.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@ultra.net X-Ultra-Time: 12 Dec 1998 19:36:58 GMT X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en,en-US,en-GB,es Xref: news3.best.com alt.sys.pdp10:4513 Eric Fischer wrote: > > If I'm understanding things correctly, text files created with SOS have > a number at the start of each line, while files created with TECO don't > have numbered lines. Is that right? TECO V23 had two filespec switches: /GENLSN (GENerate Line Sequence Numbers) -and- /SUPLSN (SUPpress Line Sequence Numbers) ERmyprog.ext/SUPLSN$$ would strip line numbers and the trailing tab on input. EWmyprog.ext/SUPLSN$$ wouldn't write line numbers on output. EBmyprog.ext/SUPLSN$$ would strip line numbers and the trailing tab on input and wouldn't write line numbers on output. EWmyprog.ext/SUPLSN$$ and EBmyprog.ext/SUPLSN$$ would retain or generate line numbers on input and would write line numbers on output. When TECO and PIP /S generated line numbers, they started at 00010, incremented by 00010. When PIP /O generated line numbers, they incremented by 00001. SOS could be told to strip LSNs on output. (It could also be told not to display them while editing; however, they were always present and could be referenced whether visible or not). True LSNs had the following specification: 1. Word-aligned, via NUL(s) after the preceeding line end. 2. 5 digits, leading zero padded. 3. Low order bit set. 4. Tab-terminated (first character of next word). Additionally, SOS wrote special form-feeds called "page marks" to separate pages. They were word-aligned, and consisted of the characters carriage return, form-feed, NUL, NUL, NUL (low-bit set). BASIC could read files whose line numbers weren't true LSNs (no leading zeros, no low order bit, no trailing tab, ...). However, I think it would write the files back out with true LSNs. /AHM -- Alan Howard Martin AMartin@MA.UltraNet.Com