TUHS September 2019

tuhs@tuhs.org

74 participants
45 discussions

Re: [TUHS] block operations in editors, was My EuroBSDcon talk

by Thomas Paulsen

--------------------------------- > > Though the vi clone with the best name was, indisputably, elvis. > unfortunately unmaintained. elvis has a smaller memory footprint, and a more pleasant (nroff later html) based help support than vim. There are no plugin, vimscript feature sas well as no python/perl support. I'm interested in a vi with syntax coloring and help support, however I don't need scripting features. Therefore I hope someone will take over maintenance, as I'm too old for tha

4 years, 7 months

block operations in editors, was My EuroBSDcon talk

by Doug McIlroy

> The "block copy in an editor" thing is something which has intrigued > me for years. poor old ed/ex/vi just couldn't do it, and for the life > of me, I could not understand why this was "deprecated" by the people > writing that family of editors. One might trace it to the founding tenet that a file is a stream of bytes, reinforced by the absence of multidemensional arrays in C. But it goes deeper than that. Ed imposes a structure, making a (finite) file into an array, aka list, of lines. It's easy to define block moves and copies in a list. But what are the semantics of a block move, wherein one treats the list as a ragged-right 2D array? What gets pushed aside? In what direction? How does a block move into column that not all destination rows reach? How do you cope when the bottom gets ragged? How about the top? Can one move blocks of tab-separated fields? I think everyone has rued the lack of block operations at one time or another. But implementing them in any degree of generality is a stumbling block. What should the semantics be? > Similarly the 'repeat this sequence of commands' thing which emacs had. Ed's g command does that, except the sequence can't contain another g. Sam, barely harder than ed to learn, cures that deficiency and generalizes in other ways, too--but has no block operations. Doug

4 years, 7 months

Re: [TUHS] [SPAM] Re: SCCS

by Norman Wilson

Peter Jeremy: > NFS ran much faster when you turned off the UDP checksums as well. > (Though there was still the Ethernet CRC32). Dave Horsfall: Blerk... That just tells you that the packet came across the wire more or less OK. ===== UDP (and TCP) checksums are nearly useless against the sort of corruption Larry described. Since they are a simple addition with carry wraparound, you can insert or remove any number of word-aligned pairs of zero octets without the checksum changing. I discovered this the hard way, while tracking down a kernel bug that caused exactly that sort of corruption. Does IPv6 require a meaningful checksum, or just the useless old ritual one? Norman Wilson Toronto ON

4 years, 7 months

Fwd: Re: earliest Unix roff

by Steffen Nurpmeso

Sorry, i said "yes" to the false question. --- Forwarded from Steffen Nurpmeso <steffen(a)sdaoden.eu> --- Date: Mon, 16 Sep 2019 21:12:28 +0200 From: Steffen Nurpmeso <steffen(a)sdaoden.eu> To: chet.ramey(a)case.edu Subject: Re: [TUHS] earliest Unix roff Message-ID: <20190916191228.1YQHs%steffen(a)sdaoden.eu> OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt Chet Ramey wrote in <95916cf9-9aa1-f949-0f37-0ae466e38aa2(a)case.edu>: |On 9/16/19 8:10 AM, Clem Cole wrote: |> I use the standalone Info reader (named info) if I want to look \ |> at the |> Info output. |> |> Fair enough, but be careful, while I admit I have not looked in a while, |> info(gnu) relies on emacs keybindings and a number of very emacs'ish th\ |> ings. |> Every time I have tried to deal with it, I have unprogram my fingers and |> reset them to emacs. |> |> If it would have used more(1) [or even less(1)] then I would not \ |> be as annoyed. | |It seems to me that the strength of info (the file format and program) is |the navigation of a menu-driven hierarchical document containing what are |essentially selectable links between sections. Something like more or less |is poorly suited to take advantage of those features. But you can do that in man macros with a normal pager like less(1), too. I mean, i may bore people, but yes i have written a macro extension for the mdoc macros which can be used to generate a TOC, and which generates document local as well as links to external manual pages. This works for all output formats, but particularly well for those which support links themselves, HTML, PDF as well as grotty, the TTY output device of groff. There was a feature request, but it has not been included yet. (My own port of roff where it will ship out of the box i just do not find time for, but i said to myself that after having banged my head a thousand times against the wall of a totally f....d up software code base, if i maintain yet another free software project then this time i do not release anything until i can say i am ready.) You can see the manual page online if you want to, it is at [1] (and itself the HTML output of a manual which uses the macro). Nothing magic, it is just that the grotty device then uses backspace escape sequences not only to embolden or otherwise format text, but also to invisibly embed content information. And a patched less(1) can search for these specially crafted backspace sequences easily, in fact i use that each and every time when i look at the manual page of the MUA i maintain, which is even longer than the bash manual. The patch for less is pretty small, even though it cares for less conventions: #?0|kent:less.tar_bomb_git$ git diff master..mdocmx|wc -l 413 [1] https://www.sdaoden.eu/code-mdocmx.html It has the deficite of not being able to dig macros as part of headers, e.g. "HISTORY ON less(1)" where less(1) would be an external link, this cannot work out the way the mdoc macros are implemented in groff. They would need to become rewritten, but no time for that yet. Other than that it works just fine for half a decade, for development i have mdoc() ( MDOCMX_ENABLE=1 \export MDOCMX_ENABLE \: ${MDOCMXFLAGS:=-dmx-toc-force=tree} \mdocmx.sh "${1}" | \s-roff -Tutf8 -mdoc ${MDOCMXFLAGS} | LESS= \s-less --RAW-CONTROL-CHARS --ignore-case --no-init ) where s-roff and s-less are the patched version. This is the development version, the nice property of mdocmx is that the preprocessing step can be shipped, in fact it is for half a decade, too. For such manuals you only need grotty/less to be patched. So then in in less i hit ^A and will be asked [anchor]: then i enter the number and it scrolls into view. And ' will scroll back to where you have been before following the internal link. Likewise, if the entered number links an external manual page you first see Read external manual: !man 1 sh and if you hit return, you go there, temporarily suspending the current less. (This external thing is actually a compile time option.) So this is all i need, and it would be very nice to have this possibility much more often. Well. The mandoc project has an option to generate links for manual pages on best guess, too. This works surprisingly well, and does not need a patch for less as it generates the usual tag files that you all know about. It cannot support exact anchor support, of course, and TOC generation it does not have too, i think. But anyway: it is possible. |You need a way to position the cursor with more flexibility than more gives |you. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) -- End forward <20190916191228.1YQHs%steffen(a)sdaoden.eu> --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)

4 years, 7 months

Re: [TUHS] earliest Unix roff [correction]

by Doug McIlroy

The URL for roff71 scans is https://www.cs.dartmouth.edu/~doug/roff71/

4 years, 7 months

user-level v1

by Doug McIlroy

The TUHS archive does not include /usr/src for v1. Does it exist anywhere? doug

4 years, 7 months

Re: [TUHS] earliest Unix roff

by Doug McIlroy

> I'd love to see the docs on that early stuff and see if Joe Ossanna > added in his own magic or was he carrying forward earlier magic. Here are scans of non-unix roff in 1971: https://www.cs.dartmouth.edu/~doug/roff71/roff71 I also have 1969, but it's bedtime and that will have to wait. Relative numbers (+n), roman numerals, .ti, top and bottom margin settings, .po, running titles, tab settings, hyphenation and footnotes were not in Saltzer's runoff. Most other features were. Doug

4 years, 7 months

CB-UNIX tapes?

by Warner Losh

I found the following in the archive: To: cbunix23(a)yahoo.com Cc: Warren(a)plan9.bell-labs.com, Toomey(a)plan9.bell-labs.com, <wkt(a)tuhs.org> Subject: Re: cb/unix tapes From: Dennis Ritchie <dmr(a)plan9.bell-labs.com> Date: Tue, 15 Jul 2003 21:23:37 -0400 They've arrived on my doorstep; thanks, Larry. 9-track drives seem thin on the ground, but we'll see. Dennis Does anybody know what became of those tapes? I know it was 13 years ago, but it's one of the few sitings of CB-Unix tapes I could find... Warner

4 years, 7 months

Re: [TUHS] SCCS

by Norman Wilson

Well, if we're going to get into editor, erm, version-control wars, I'll state my unpopular opinion that SCCS and RCS were no good at all and CVS only pretended to be any good. Subversion was the first system I could stand using. The actual basis for that opinion (and it's just my opinion but it's not pulled out of hyperspace) is that the older systems think only about one file at a time, not collections of files. To me that's useless for any but the most-trivial programming (and wasn't non-trivial programming what spurred such systems?). When I am working on a non-trivial program, there's almost always more than one source file, and to keep things clean often means refactoring: splitting one file into several, merging different files, removing files that contain no-longer-useful junk, adding files that implement new things, renaming files. A revision-control system that thinks only about one file at a time can't keep track of those changes. To me that makes it worse than useless; not only can it not record a single commit with a single message and version number when files are split and combined, it requires extra work to keep all those files under version control at all. CVS makes an attempt to handle those things, but the effect is clunky in practice compared to successors like svn. One shouldn't underestimate the importance of a non-clunky interface. In retrospect it seems stupid that we didn't have some sort of revision control discipline in Research UNIX, but given the clunkiness of SCCS and RCS and CVS, there's no way most of us would have put up with it. Given that we often had different people playing with the same program concurrently, it would have taken at least CVS to meet our needs anyway. Norman `recidivist' Wilson Toronto ON

4 years, 7 months

Livermore software tools dist

by Arnold Robbins

See https://drive.google.com/file/d/0ByJs3HoO8aRVd1JlOGJWRlJhTDg/view which seems to be stuff from 1984 and 1988. I have no idea where it came from or anything else; I stumbled across it while looking for some other things. Thanks, Arnold

4 years, 7 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS September 2019