> 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
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
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)
> 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
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
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
George Michaelson writes:
> What Larry and the other RCS haters forget is that back in the day,
> when we all had more hair, RCS was --->FAST<--- and SCCS was S.L.O.W.
>
> because running forward edits on a base state of 1000 edits is slow.
> Since the majority action is increment +1 on the head state the RCS
> model, whilst broken in many ways
> was FAST
>
> -G
And also that RCS had a much friendlier interface.
