15 Sep
2024
15 Sep
'24
2:37 p.m.
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
15 Sep
15 Sep
7:21 p.m.
New subject: On computerese
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'...
Rik
On Sun, Sep 15, 2024 at 7:38 AM Douglas McIlroy <
douglas.mcilroy(a)dartmouth.edu> wrote:
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
8:43 p.m.
New subject: On computerese
Early on, here in Faraway Land, I was told Unix command naming rules were these:
however can’t recall seeing it written:
2-7 chars - ie. short + reserved single chars for personal use
lower case
non-dictionary words - allowing 3rd party software a clear run
Of course, “sort” fails those rules :)
BSD didn’t use those rules (backup & restore).
For non touch typists, shorter commands & keywords are helpful.
On 16 Sep 2024, at 05: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'...
Rik
--
Steve Jenkin, IT Systems and Design
0412 786 915 (+61 412 786 915)
PO Box 38, Kippax ACT 2615, AUSTRALIA
mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin
16 Sep
16 Sep
12:49 a.m.
New subject: On computerese
Sorry, my 'eh?' was an ironic reference to the cryptic error messages from
ed.
=====
nygeek.net
mindthegapdialogs.com/home <https://www.mindthegapdialogs.com/home>
On Sun, Sep 15, 2024 at 5:41 PM Dave Horsfall <dave(a)horsfall.org> wrote:
[ Undoing top-posting ]
On Sun, 15 Sep 2024, Marc Donner wrote:
What needs to be clarified?
-- Dave
BSD
didn’t use those rules (backup & restore).
dump/restor (no "e"), as I recall?
eh? 
15 Sep
15 Sep
7:36 p.m.
New subject: On computerese
Before I got hooked on UNIX in 1977, I used a Univac Exec8 system.
You “cataloged” (created) a file with the @CAT command.
Other, file operations were done by the File Utility Routine/Program
Utility Routine: FURPUR
(sort of like pip on steroids).
I decided that if I ever got a CAT, it would be named FURPUR. That
happened when I was working for Rutgers. Not having any UNIVACs
around, the name escaped notice until the EE department hired a guy from
the University of Maryland who says “You have a cat named FURPUR?”
16 Sep
16 Sep
5:36 a.m.
New subject: On computerese
Every computer geek knows his/her cat is the Computer Purry Furr-all ...
don't say you weren't warned! :)
Wesley Parish
On 16/09/24 07:36, Ron Natalie wrote:
Before I got hooked on UNIX in 1977, I used a Univac
Exec8 system.
You “cataloged” (created) a file with the @CAT command.
Other, file operations were done by the File Utility Routine/Program
Utility Routine: FURPUR
(sort of like pip on steroids).
I decided that if I ever got a CAT, it would be named FURPUR. That
happened when I was working for Rutgers. Not having any UNIVACs
around, the name escaped notice until the EE department hired a guy
from the University of Maryland who says “You have a cat named FURPUR?”
3:10 a.m.
New subject: On computerese
Douglas McIlroy <douglas.mcilroy(a)dartmouth.edu> wrote:
But brevity is the defensible argument for
"catenate", while
familiarity boosts "concatenate".
I suspect that only "highly educated east-coasters" are
familiar with "catenate." My education was pretty good,
but catenate, for all it's advantages of brevity and similar
age to "concatenate" is simply never used in modern-day
American English.
I'd never heard it until, like just about all the rest of
us, I came across it in the Unix manual.
My $.02,
Arnold
3:30 a.m.
New subject: On computerese
cat is capable of endless discussion.
cat thing | cat otherthing doesn't do what (some) people think.
cat thing | cat otherthing /dev/stdin does, but there's an ordering
point to be made.
cat thing | cat < otherthing /dev/stdin makes the ordering point. and
the number of lines seen.
the role of the shell in marshalling the IO and determining what is
opened, when, truncated is another pitfall that seems to escape
people. "I thought the commands ran left to right" when your first
command < something and your final command > something
like others, my use of cat is reflexive. I know perfectly well I could
solve the whole problem in awk or sed, I still construct sequences to
use sed to edit the lines, and awk to extract the fields in LSWP
denoted counts. we're speaking english and say "comme ci comme ca" and
nobody blinks, it's the same in shell. codeswitching!
10:41 a.m.
New subject: On computerese
On Monday, September 16, 2024, George Michaelson <ggm(a)algebras.org> wrote:
cat is capable of endless discussion.
cat thing | cat otherthing doesn't do what (some) people think.
cat thing | cat otherthing /dev/stdin does, but there's an ordering
point to be made.
cat thing | cat < otherthing /dev/stdin makes the ordering point. and
the number of lines seen.
the role of the shell in marshalling the IO and determining what is
opened, when, truncated is another pitfall that seems to escape
people. "I thought the commands ran left to right" when your first
command < something and your final command > something
like others, my use of cat is reflexive. I know perfectly well I could
solve the whole problem in awk or sed, I still construct sequences to
use sed to edit the lines, and awk to extract the fields in LSWP
denoted counts. we're speaking english and say "comme ci comme ca" and
nobody blinks, it's the same in shell. codeswitching!
I have always admired one letter commands in ed(1) and during the years
constructed my own personal perfect Unix dictionary with most often used
commands as one letter abbreviations. For cat(1) I have always used 'c'
(cee) which also denotes one of its main functions.
Grep(1) is 'g', vi(1) is 'v', etc.
It makes typing a little faster, at least for me.
--Andy
10:59 a.m.
New subject: On computerese
George Michaelson <ggm(a)algebras.org> writes:
cat is capable of endless discussion.
cat thing | cat otherthing doesn't do what (some) people think.
cat thing | cat otherthing /dev/stdin does, but there's an ordering
point to be made.
cat thing | cat < otherthing /dev/stdin makes the ordering point. and
the number of lines seen.
I'm not sure of the point you are making with your last example, which
gave me pause. I had to run it to see what it does.
I correctly guessed that only one of thing or otherthing would be printed,
but I was not able to guess if the | or the < would take precedence.
Is there a simple reason why the < has priority over | for the stdin ?
If the < precedence was your point, why did you specify /dev/stdin ?
cat thing | cat < otherthing
makes the point.
Is there a finer point I am missing ?
Sorry for being dense. I'm happy, after more that 20 years of Unixing,
to see something new even with such supposedly basic commands. Thank you
for your brain twister.
8:55 p.m.
New subject: On computerese
On Mon, Sep 16, 2024 at 7:31 AM Edouard Klein <edouardklein(a)gmail.com> wrote:
George Michaelson <ggm(a)algebras.org> writes:
I suppose this depends entirely on the shell; perhaps that is the
point. Arguably, being the target of a pipe _and_ having a redirect on
stdin should be some kind of an error, but regardless, something that
is true is that is that the second `cat` command will only see
whatever is on `stdin` as it reads from `/dev/stdin`, but what is _on_
stdin can be confusing.
- Dan C.
cat is capable of endless discussion.
cat thing | cat otherthing doesn't do what (some) people think.
cat thing | cat otherthing /dev/stdin does, but there's an ordering
point to be made.
cat thing | cat < otherthing /dev/stdin makes the ordering point. and
the number of lines seen.
I'm not sure of the point you are making with your last example, which
gave me pause. I had to run it to see what it does.
I correctly guessed that only one of thing or otherthing would be printed,
but I was not able to guess if the | or the < would take precedence.
Is there a simple reason why the < has priority over | for the stdin ? If the < precedence was your point, why did you
specify /dev/stdin ?
cat thing | cat < otherthing
makes the point.
Is there a finer point I am missing ?
Sorry for being dense. I'm happy, after more that 20 years of Unixing,
to see something new even with such supposedly basic commands. Thank you
for your brain twister.
9:05 p.m.
New subject: On computerese
On 9/16/24 4:55 PM, Dan Cross wrote:
POSIX actually speaks on this:
"The standard input, standard output, or both of a command shall be
considered to be assigned by the pipeline before any redirection specified
by redirection operators that are part of the command"
https://pubs.opengroup.org/onlinepubs/9799919799/utilities/V3_chap02.html#t…
In the general case, this is how things like
program 2>&1 | collect_stdout_and_stderr
can work (file descriptor 1 is associated with the pipe before fd 2 is
redirected to it).
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU chet(a)case.edu http://tiswww.cwru.edu/~chet/
I correctly
guessed that only one of thing or otherthing would be printed,
but I was not able to guess if the | or the < would take precedence.
Is there a simple reason why the < has priority over | for the stdin ?
I suppose this depends entirely on the shell; perhaps that is the
point.
3
days inactive
4
days old
14 comments
13 participants
participants (13)
-
Andy Kosela -
arnold＠skeeve.com -
Chet Ramey -
Dan Cross -
Dave Horsfall -
Douglas McIlroy -
Edouard Klein -
George Michaelson -
Marc Donner -
Rik Farrow -
Ron Natalie -
sjenkin＠canb.auug.org.au -
Wesley Parish