Hi,
ed(1) pre-dates pipes. When pipes came along, stderr was needed, and
lots of new idioms were found to make use of them. Why didn't ed gain a
`filter' command to accompany `r !foo' and `w !bar'?
To sort this paragraph, I
;/^$/w !sort >t
;/^$/d
-r t
I'd have thought that filtering was common enough to suggest a `^'
command with an implied `!'? (Not `|' since that was uncommon then.)
ex(1) has `!' that filters if applied to a range of lines, and this
carries through to vi's `!' that's often heavily used, especially when
the "file" is just a scratch buffer of commands, input, and output.
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
There's a story I heard once in supercomputing circles from the 80s, that
Ken visited CRI in Minneapolis, sat down at the console of a machine
running the then-new port of Unix to one of the Crays, typed a command, and
said something like "ah, that bug is still there."
Anybody know what the bug was?
It's time to assert my editorial control and say: no more 80 cols please!
Anybody who mentions 80 cols will be forced to use either a Hazeltine or
an ADM3 (not 3a) for a month.
Thanks, Warren
Jim "wkt" Moriarty:
> Anybody who mentions 80 cols will be forced to use either a Hazeltine or
> an ADM3 (not 3a) for a month.
=====
So who has a modern emulator for either of those terminals?
Norman Wilson
Toronto ON
(Still not really in Toronto, but no longer in Texas)
Does anyone know if the image
http://www.tuhs.org/Archive/Distributions/Research/Dennis_v6/v6root.gz
is somehow bootable as-is?
I wasn't able to figure out how to get it to boot, so I went on a quest
to make it bootable. Here's what I did - let me know if this was
overkill or misguided.
Basically, I downloaded the known bootable v6 distribution tape from
Wellsch directory in TUHS. I then extracted 101 blocks from the image
(tmrk, a bootblock, and who knows what else, but seriously what else is
on those first 100 blocks?), converted it to a simh compatible tape
format, and booted a simh generic pdp11/40 with my new little boot tape
and Dennis's root disk attached. I used tmrk to copy the bootstrap from
my little tape to Dennis's root disk (am I clobbering anything
important?). Then voila - it was bootable :)! I could have done it
straight off Ken's tape (after converting it to a simh tape format), but
I wanted to keep the little tape image around for use in other contexts.
Details for the curious are here:
https://decuser.github.io/bootable-tape-v6.txt
I thought the Ken Wellsch tape was basically the same as the Dennis
Ritchie disks, but now I'm not so sure - on Ken's tape, it boots to:
@rkunix
mem = 1035
RESTRICTED RIGHTS
Use, duplication or disclosure is subject to
restrictions stated in Contract with Western
Electric Company, Inc.
#
on Dennis' it boots to:
@rkunix
mem = 1036
#
Makes me curious to see what else is different. Maybe Dennis's was prior
to preparing an official distro where the rights were added to the kernel?
Will
--
GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF
Nemo:
And for that reason, I have never used Python. (I have a mental block
about that.)
====
I used to feel the same way. A few years ago I held my nose
and jumped in. I'm glad I did; Python is a nifty little
language that, now I know it, hits a sweet spot twixt low-level
C and high-level shell and awk scripts.
Denoting blocks solely by indentation isn't at all bad once
you do it; no worse than adapting from do ... end to C's {}.
What still bugs me about Python:
-- It is unreasonably messy to give someone else a copy of
a program composed of many internal modules. Apparently
you are expected to give her a handful of files, to be
installed in some directory whose name must be added to
the search path in every Python source file that imports
them. I have come up with my own hacky workaround but it
would be nice if the language provided a graceful way to,
e.g., catenate multiple modules into a single source file
for distribution.
-- I miss C's style of for loop, though not often. (Not
quite everything can be turned into a list or an iterator.)
-- I miss one particular case of assigment having a value:
that of
while ((val = function()) != STOP)
do something with val
Again, there are clunky ways to work around this.
As for 80 columns, I'm firmly in the camp that says that
if you need a lot of indentation you're doing it wrong.
Usually it means you should be pulling the details out
into separate functions. Functions that run on for many,
many lines (once upon a time it was meaningful to say
for many pages, but no longer) are just as bad, for the
same reason: it's hard to read and understand the code,
because you have to keep so many details in your head at
once.
Likewise for excessive use of global variables, for that
matter, a flaw that is still quite common in C code.
Having to break an expression or a function call over
multiple lines is more problematic. It's clearer not
to have to do that. It helps not to make function or
variable names longer than necessary, but one can carry
that too far too.
Style and clarity are hard, but they are what distinguishes
a crap hack programmer from a good one.
Norman Wilson
Toronto ON
(Sitting on the lower level of a train in Texas,
not on a pedestal)
So, 80 column folks, would you find this
a(b,
c,
d)
more readable than
a(b,c,d)
(this is a real example, with slightly shortened names)
would you have code review software that automatically bounces out lines
that are 82 columns wide? How far does this go?
I do recall 80 column monitors, but I started on 132 column decwriter IIs
and hence have never had sympathy for 80 columns. It's weird that so many
punched-card standards are required in our code bases now (see: Linux).
moving away from serious ... (look for Presottos' I feel so liberated ...)
http://comp.os.plan9.narkive.com/4W8iThHW/9fans-acme-fonts
Hi,
Everyone on the list is well aware that running V7 in a modern simulator
like SIMH is not a period realistic environment and some of the
"problems" facing the novice enthusiast are considerably different from
those of the era (my terminal is orders of magnitude faster and my
"tape" is a file on a disk). However, many of the challenges facing
someone in 1980, remain for the enthusiast, such as how to run various
commands successfully and how devices interoperate with unix. Of course,
we have do resources and some overlapping experience to draw on -
duckduckgo (googleish), tuhs member experience, and exposure to modern
derivatives like linux, macos, bsd, etc. We also have documentation of
the system in the form of the Programmer's Guide - as pdfs and to some
degree as man pages on the system (haven't found volume 2 documentation
on the instance).
My question for you citizens of that long-ago era :), is this - what was
it like to sit down and learn unix V7 on a PDP? Not from a hardware or
ergonomics perspective, but from a human information processing
perspective. What resources did you consult in your early days and what
did the workflow look like in practical terms.
As an example - today, when I want to know how to accomplish a task in
modern unix, I:
1. Search my own experience and knowledge. If I know the answer, duh, I
know it.
2. Decide if I have enough information about the task to guess at the
requisite commands. If I do, then man command is my friend. If not,
I try man -k task or apropos task where task is a one word summary
of what I'm trying to accomplish.
3. If that fails, then I search for the task online and try what other
folks have done in similar circumstances.
4. If that fails, then I look for an OS specific help list
(linux-mint-help, freebsd forums, etc), do another search there, and
post a question.
5. If that fails, or takes a while, and I know someone with enough
knowledge to help, I ask them.
6. I find and scan relevant literature or books on the subject for
something related.
Repeat as needed.
Programming requires some additional steps:
1. look at source files including headers and code.
2. look at library dependencies
3. ask on dev lists
but otherwise, is similar.
In V7, it's trickier because apropos doesn't exist, or the functional
equivalent man -k, for that matter and books are hard to find (most deal
with System V or BSD. I do find the command 'find /usr/man -name "*" -a
-print | grep task' to be useful in finding man pages, but it's not as
general as apropos.
So, what was the process of learning unix like in the V7 days? What were
your goto resources? More than just man and the sources? Any particular
notes, articles, posts, or books that were really helpful (I found the
article, not the book, "The Unix Programming Environment" by Kernighan
and Mashey, to be enlightening
https://www.computer.org/csdl/mags/co/1981/04/01667315.pdf)?
Regards,
Will
