The florid syntax of IBM's DD was rivaled by that of GE's file utility. I
always wondered whether it was named FUTIL unwarily or with tongue in cheek.
Doug
> Who created the "cat" command and did they have the
> word "catenate" or "concatenate" in their heads?
Ken Thompson wrote "cat" for the PDP-7, with "concatenate" in
mind. The cat(1) page in the v1 manual is titled, "concatenate (or
print) files". Only later did someone in Research--I don't know
who--remark on the existence of the shorter synonym. It was
deliberately adopted in v7, perhaps because it better mirrored
the command name.
But brevity is the defensible argument for "catenate", while
familiarity boosts "concatenate". It stll takes some conscious
effort for me to use the former, However, I sense sinister
vibes in "concatenate", driven by the phrase "concatenation
of events", which often is used to explain misfortune.
Doug
> From: Rik Farrow <rik(a)rikfarrow.com>
> Was the brevity typical of Unix command names a function of the tiny
> disk and memory available? Or more a function of having a Teletype 33
> for input?
I'm not sure the answer was ever written down (e.g. in a memo); we will
probably have to rely on memory - and memories that far back are now fairly
thin on the ground by now. Perhaps Mr. McIlroy (or Mr. Thompson, if we're
_really_ lucky) will humor us? :-)
I have the impression that some of the names are _possibly_ inherited from
Multics (which the early Unicians all used before Unix existed) - but maybe
not. The command to list a directory, on Multics, is 'ls' (but see below) -
but the Multics qcommand to remove a file is 'del' (not 'rm'); and change working
directory is 'cwd'. So maybe ls' is just chance?
Multics had a 'feature' where a segment (file) could have additional names (to
the main name), and this is used to add short aliases to many commands, so the
'base name'' for the directory list command is 'list'; 'ls' is a short
alias. A list of Multics commands (with short forms) is available here:
https://www.multicians.org/multics-commands.html
I'm not sure how early that alias mechanism came in, though; my copy of
"Introduction to Multics" (February, 1974) doesn't have short names (or, at
least, it doesn't use them).
It won't have anything to do with disk and memory. Having used a Teletype, it
would take noticeably longer to type in a longer name! It's also more effort
and time. I would expect those are the reasons for the short names.
Noel
> On 15 Sep 2024, at 20:21, Rik Farrow <rik(a)rikfarrow.com> wrote:
>
> Was the brevity typical of Unix command names a function of the tiny disk and memory available? Or more a function of having a Teletype 33 for input? Of course, it could simply be that 'cat' is more convenient than 'catenate'...
Hangover from assembly mnemonics, perhaps.
J
—
John Dow <jmd(a)nelefa.org>
Written by a human.
> https://retronaut.com/retronaut-capsules/1967-life-at-bell-labs
Luckham's introductory remark that all the programmers were men contrasts
with the situation 10 years before, when most of the programmers were
women. Women got shoved aside when it became apparent that programming was
an honorable and challenging engineering profession, not mere routine
translation of conceptual designd into machine language. It took almost 10
more years for the Labs to recognize that women programmers were engineers,
too.
Yet de jure recognition of women programmers has not yet become de facto.
Here at Dartmouth, as at many schools, women form a far smaller fraction of
computer science than they do of the engineering school. In engineering the
proportion of women reflects that in the general population.
Hi all,
I was working with my IRIX 4 machine recently and noticed a mysterious file
- /usr/lib/ecfe. It turns out that this is the Edison Design Group C (not
C++) Front End, included almost certainly by accident with the last release
of the Developer Toolkit for IRIX 4. No other piece of the compiler
toolchain references the EDG product in any way and there is no
documentation for it whatsoever.
The research that I did seems to indicate that this is a source to source
translator, akin to the contemporary Kuck & Associates product - is that
correct? I also found a reference to EDG's tool being used in the Apogee C
compiler. I have a copy of Apogee C for SunOS and it does appear that
"cfe" is the same EDG product. Unfortunately there is no documentation
specific to the C front end, and I don't have a license for Apogee C so I
can't run the compiler to see how it's calling cfe. Just running a C file
"blah.c" through the IRIX front end with no switches results in a
transformed file "blah.int.c". Unfortunately running anything even
moderately complex through the front end results in code that either
doesn't compile or doesn't run, so I feel that I must be missing some flags
or basic options.
Does anyone have any information about SGI's use of this software, or any
documentation/information in general about the EDG product? My usual
sources came up empty.
-Henry
>> I've despaired over the term ever since it wormed its way into
>> computer folks' vocabulary. How does a "use case" differ from a "use"?
>
> Clarity as to whether one is employing a noun or a verb. Both "use" and
> "case" can be either (he said, casing the joint for tomorrow's heist),
> but juxtaposing them thus unambiguously makes a noun phrase.
Usually context makes the nominal use of "use" clear : "many uses", "the
use",
"some uses". I'm not persuaded that "use case" disambiguates any more
reliably.
How do supermarkets display their wares?
For some use cases they use cases.
Metacomment. While the "use" in "nominal use" above must be a noun,
"nominal" isn't compelled to have the intended meaning of "being a noun".
It's a game of whac-a-mot. Kill one ambiguity and spawn another.
Doug
Two remarks about Plan 9, one about an antecedent and the other about the
limits of its influence.
"Communication files" in the Dartmouth Time Sharing System have been cited
as a predecesssor of Unix pipes, although we at Bell Labs were unaware of
the DTSS feature when pipes were first implemented. In fact, communication
files more directly foreshadow Plan 9 than they do Unix.
Unlike Unix processes, which need not be aware that they are talking to
pipes, the process at one end of a communication file, designated as
"master", must be aware that it is a communication file. The master end
controls the semantics of reads, writes and seeks(!) issued at the other
end. Because of this asymmetry, a communication file cannnot serve as a
pipe between pairs of unprepared processes. A pipe could be simulated in
DTSS by a master process that relays flow between communications files
connected to arbitrary end processes, but that seems never to have been
done.
Communication files are a closer antecedent to Plan 9. A master process's
controls correspond to the part of Plan 9's foundational 9P protocol that
handles open files. Though I don't think there's an actual ancestral
connection, this likeness strengthens DTSS's claim to fame and extends
their lead to nearly a quarter century.
Linux has adopted surface features of Plan 9 like union directories,
append-only files and system data access via file interfaces. Meanwhile
Plan 9's revolutionary realization of what Vic Vyssotsky called
distributable computing has not caught on. In distributable computing, the
physical location of processes does not affect their logical interaction.
In today's distributed computing, though, there is a world of difference
between how processes interact remotely and locally. When will the crevasse
between the possible and the normal be bridged?
Doug
Having recently read about the playful literary consortium, Oulipo, I am
reminded of their term for little-known antecedents of their revolutionary
works: "anticipatory plagiarism".
Long before there was Markdown, there was a similar Unix tool. I remember
reading about it before the Internet was popular, probably mid-to-late
1980s. I may have read about it in “Communications of the ACM”.
It was designed to let secretaries compose memos, without learning the dot
commands of troff or nroff. If you indented a space or two, it started a
new paragraph. If you indented several spaces, it centered the line; very
similar to Markdown in concept. It generated a file that could be fed into
troff.
I was thinking it might have been part of the System V Documentors
Workbench, but I read through the doc for it and could not find anything
like that.
Does anyone remember this?
Thanks!
