25 Mar
2016
25 Mar
'16
8:43 p.m.
Hi TUHSers,
For a long time now, I have had a theory that I've never seen
substantiated (or disproved) in print. After Steve Johnson's recollection
of how hard it was to type on the Teletype terminals, I'm going to throw
this thought out for consideration.
One of Unix's signature hallmarks is its terseness: short command names
like mv, ln, cp, cc, ed; short options (a dash and a single letter),
programs with just a few, if any, options at all, and short path names:
"usr" instead of "user", "src" instead of "source"
and so on.
I have long theorized that the reason for the short names is that since
typing was so physically demanding, it was natural to make the command
names (and all the rest) be short and easier to type. I don't know if
this was a conscious decision, but I suspect it more likely to have been
an unconscious / natural one.
Today, I started wondering if this wasn't at least part of the reason
for commands being simple, with few if any options. After all, if I
have to type 'man foo' to remember how foo works, I don't want to wait
for 85 pages of printout (at 110 characters per second!) to finally see
what option -z does after wading through the descriptions of options -a
through -y.
I certainly think there's some truth to this idea; longer command
names and especially GNU style long options didn't appear until the
video terminal era when terminals were faster (9600 or 19200 baud!) and
much less physically demanding to use. How MUCH correlation is there,
I don't claim to know, but I think there's definitely some.
For the record, I did use the paper teletypes some, mainly at a university
where I took summer classes, connected to a Univac system. I remember
how hard it was to use them. You could almost set your watch by when
it would crash around noon time, as the load went up. :-) On Unix I
only used VDTs, except if I was at a console DECwriter.
Anyway, that's my thought. :-) Comments and or insights, especially from
those who were there, would be welcome.
Thanks,
Arnold
26 Mar
26 Mar
1:47 a.m.
<SNIP>
One of Unix's signature hallmarks is its terseness: short command names
like mv, ln, cp, cc, ed; short options (a dash and a single letter),
programs with just a few, if any, options at all, and short path names:
"usr" instead of "user", "src" instead of
"source" and so on.
<SNIP>
Peter Collinson wrote in 1983 an article on this subject. It is
available at <http://www.hillside.co.uk/articles/typing.html>.
jaap
3:03 a.m.
On 25/03/2016 16:43, Aharon Robbins wrote:
I have long theorized that the reason for the short
names is that since
typing was so physically demanding, it was natural to make the command
names (and all the rest) be short and easier to type. I don't know if
this was a conscious decision, but I suspect it more likely to have been
an unconscious / natural one.
In a paper we will present at this year's International Conference on
Software Engineering we show (among other things) that the mean length
of identifiers in Unix C source code has risen from 3.5 to 7.5
characters from 1973 until today. We also observed a corresponding rise
in the length of lines and files. Better terminals can be one reason for
this rise. Other possible reasons may be increased software complexity
as well as CPU power and memory that allowed the processing of more
verbose code.
I've uploaded a preprint at
http://www.dmst.aueb.gr/dds/pubs/conf/2016-ICSE-ProgEvol/html/SLK16.pdf
29 Mar
29 Mar
2:12 a.m.
On 25/03/2016 16:43, Aharon Robbins wrote:
... and I once heard an old-timer growl at a young programmer "I've
written boot loaders that were shorter than your variable names!"
Steve
I have long theorized that the reason for the
short names is that since
typing was so physically demanding, it was natural to make the command
names (and all the rest) be short and easier to type. I don't know if
this was a conscious decision, but I suspect it more likely to have been
an unconscious / natural one.
In a paper we will present at this year's International Conference on
Software Engineering we show (among other things) that the mean length
of identifiers in Unix C source code has risen from 3.5 to 7.5
characters from 1973 until today. We also observed a corresponding rise
in the length of lines and files. Better terminals can be one reason for
this rise. Other possible reasons may be increased software complexity
as well as CPU power and memory that allowed the processing of more
verbose code.
I've uploaded a preprint at
http://www.dmst.aueb.gr/dds/pubs/conf/2016-ICSE-ProgEvol/html/SLK16.pdf
1 Apr
1 Apr
8:06 p.m.
On Mon, 28 Mar 2016, scj(a)yaccman.com wrote:
... and I once heard an old-timer growl at a young
programmer "I've
written boot loaders that were shorter than your variable names!"
Ah, the 512-byte boot blocks... We got pretty inventive in those days
(and this was before secondary loaders!) with line editing etc.
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."
2 Apr
2 Apr
4:41 a.m.
On Saturday, 2 April 2016 at 1:06:58 +1100, Dave Horsfall wrote:
On Mon, 28 Mar 2016, scj(a)yaccman.com wrote:
I was thinking more of the RIM loader on the PDP-8. 16 words or 24
bytes.
Greg
--
Sent from my desktop computer.
Finger grog(a)FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed. If your Microsoft MUA reports
problems, please read http://tinyurl.com/broken-mua
... and I once heard an old-timer growl at a
young programmer "I've
written boot loaders that were shorter than your variable names!"
Ah, the 512-byte boot blocks... We got pretty inventive in those days
(and this was before secondary loaders!) with line editing etc. 
26 Mar
26 Mar
3:29 a.m.
New subject: Command-line options
On Fri, Mar 25, 2016 at 05:43:08PM +0300, Aharon Robbins wrote:
One of Unix's signature hallmarks is its
terseness: short command names
like mv, ln, cp, cc, ed; short options (a dash and a single letter),
programs with just a few, if any, options at all, and short path names:
"usr" instead of "user", "src" instead of
"source" and so on.
I have long theorized that the reason for the short names is that since
typing was so physically demanding, it was natural to make the command
names (and all the rest) be short and easier to type. I don't know if
this was a conscious decision, but I suspect it more likely to have been
an unconscious / natural one.
I'm going to throw in an aside at this point. PDP-7 Unix packed 2 characters
per 18-bit word. So, when comparing things, it's easy to compare one
word against another. I believe this is why command-line options were
2 characters (e.g. -l, -v, -c, -d) etc.
Cheers, Warren
5:25 a.m.
New subject: Command-line options
On Saturday, 26 March 2016 at 7:29:25 +1000, Warren Toomey wrote:
On Fri, Mar 25, 2016 at 05:43:08PM +0300, Aharon
Robbins wrote:
Really? Most machines of that era used 6 bit characters, so you could
fit 3 in an 18 bit word. I had hypothesized that that was the reason
for word lengths in increments of 6 bits in those days.
One of Unix's signature hallmarks is its
terseness: short command names
like mv, ln, cp, cc, ed; short options (a dash and a single letter),
programs with just a few, if any, options at all, and short path names:
"usr" instead of "user", "src" instead of
"source" and so on.
I have long theorized that the reason for the short names is that since
typing was so physically demanding, it was natural to make the command
names (and all the rest) be short and easier to type. I don't know if
this was a conscious decision, but I suspect it more likely to have been
an unconscious / natural one.
I'm going to throw in an aside at this point. PDP-7 Unix packed 2
characters per 18-bit word. So, when comparing things, it's easy to compare
one word against
another. I believe this is why command-line options were 2
characters (e.g. -l, -v, -c, -d) etc.
You've seen the code, of course. Is that how it was done?
It's interesting to note that large UNIVAC systems in those days had a
similar option syntax. The 1100 series would add them after a comma.
Here an example from a random command file:
@ASG,AX UNIVAC*DVP5.
@ASG,T DST1.,F14/88/TRK/88
ASG meant "assign", and the options were after the comma. I'm a bit
vague about the exact meaning of the options, but they both associated
files with the current job.
The 494 did things slightly differently: there was no comma, and the
options came as a group, so instead of "@ASG,T" you might write
"#ASG T". This is very reminiscent of some early Unix stuff, such as
tar. The options were parsed by the shell equivalent (forget the
name) and packed into a single word bitmap.
In passing, it's interesting to note that the initial @ or # were used
to identify a command. Other systems of the time did similar things.
My guess is that the command prompt in Unix started life as a "here's
your command leadin for free".
I don't think that Unix inherited anything from UNIVAC; it's more
likely that the similarities are indicative of common descent.
Greg
--
Sent from my desktop computer.
Finger grog(a)FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed. If your Microsoft MUA reports
problems, please read http://tinyurl.com/broken-mua
8:10 a.m.
New subject: Command-line options
Greg 'groggy' Lehey scripsit:
So they did, but DEC machines in general were always ASCII. The PDP-8
used both 8-bit characters (ASCII with the high bit set) and 6-bit
ones (stripped ASCII without control characters or lower-case ones).
The former were packed three 8-bit characters in two 12-bit words; the
latter, two characters in one 12-bit word. The PDP-10 packed five 7-bit
characters into a 36-bit word with one bit left over, which was used
(if at all) for various purposes. Not until the PDP-11 did the 8-bit
character get aligned with the machine word size.
I'm going
to throw in an aside at this point. PDP-7 Unix packed 2
characters per 18-bit word.
Really? Most machines of that era used 6 bit characters, so you could
fit 3 in an 18 bit word. I had hypothesized that that was the reason
for word lengths in increments of 6 bits in those days. In passing, it's interesting to note that the
initial @ or # were used
to identify a command. Other systems of the time did similar things.
My guess is that the command prompt in Unix started life as a "here's
your command leadin for free".
All DEC systems had command prompts of the Unix type, though not changeable:
the original prompt was simply ".". In the DOS/BATCH-11 operating system,
however, the shell-level command prompt was $ and the intra-command prompt
was *, and you wrote batch files with explicit $ and * sigils, so that
a $-marked line implicitly indicated the end of input for the previous
command, a compact equivalent of here-scripts.
--
John Cowan http://www.ccil.org/~cowan cowan(a)ccil.org
To say that Bilbo's breath was taken away is no description at all. There are
no words left to express his staggerment, since Men changed the language that
they learned of elves in the days when all the world was wonderful. --The Hobbit
9:09 a.m.
New subject: Command-line options
On Fri, Mar 25, 2016 at 7:10 PM, John Cowan <cowan(a)mercury.ccil.org> wrote:
So they did, but DEC machines in general were always ASCII. The PDP-8
used both 8-bit characters (ASCII with the high bit set) and 6-bit
ones (stripped ASCII without control characters or lower-case ones).
The former were packed three 8-bit characters in two 12-bit words; the
latter, two characters in one 12-bit word. The PDP-10 packed five 7-bit
characters into a 36-bit word with one bit left over, which was used
(if at all) for various purposes. Not until the PDP-11 did the 8-bit
character get aligned with the machine word size.
And Dec's RADIX-50, packing 3 characters into 16 bits. (IIRC the origin of
the 6.3 filenames. bit I can't document that.)
-- Charles
27 Mar
27 Mar
1:43 a.m.
New subject: Command-line options
On Fri, Mar 25, 2016 at 11:09 PM, Charles Anthony <
charles.unix.pro(a)gmail.com> wrote:
And Dec's RADIX-50, packing 3 characters into 16
bits. (IIRC the origin of
the 6.3 filenames. bit I can't document that.)
Sort of.... before ASCII, DEC used a few other 5 bit codes that were
around such as baudot (look at the PDP-1/4 etc and KSR 28). RAD50 was a
natural scheme for storing file name and using bits efficiently.
Which, of course, lead to the abomination of case folding - it's not a bug,
it's a feature 😂
RAD50 gave us the x.y file name form with the implied dot et al. 6.3 and
later 8.3 were natural directions from that coding. Using the .3 ext as a
type tag of course followed that naturally given that's all that was stored
in the disk "catalog." [And CP/M and PC/MS-DOS inherit that scheme -
including the case folding silliness even though by that time all keyboard
were upper and lower case and they stored the files in 8 bits].
UNIX of course, would put the "type" in the file itself (magic #) and force
the storing of the dot, but removed the strict mapping of name and type.
Having grown up in both systems, I see the value of each; but agree I think
I find UNIX's scheme better and lot more flexible.
What is funny is that Apple's OSX does it both ways which I find
schizophrenic and my major complaint with OSX (which is still my current
fave but that's another story).
Clem
2:54 a.m.
New subject: Command-line options
More strictly, UNIX doesn’t have “type” in a file. They’re just a bunch of bytes. It’s
up to whoever is making the file to decide if the name conveys that information or a magic
number does.
The other fun character set was the old UNIVAC Fielddata. There were no non printing
characters and in fact not even a null value (the 0 value was called master space and
printed as @).
4:05 a.m.
New subject: Command-line options
Ronald Natalie scripsit:
More strictly, UNIX doesn’t have “type” in a file.
They’re
just a bunch of bytes. It’s up to whoever is making the file to
decide if the name conveys that information or a magic number does.
True. On the IBM PC AT I mentioned earlier, I needed a number of binary
file formats, as it was clear that ASCII-binary conversion was too slow
for the purpose. (Probably not true even then, but what did I know?)
So I duly assigned 16-bit magic numbers for each file format, and
#define'd them in the code. Where did the magic come from? They were
RAD50 encodings of three-letter file codes!
Johnny Billquist scripsit:
On the PDP-8, you sometimes saw @ used as a prefix
character in
SIXBIT. So you'd use @M to get a CR, and @J for an LF, and @@ would
mark the end of the string. But not for filenames. But in code, since
you sometimes used SIXBIT for string constants as well.
Yes, I think that's what I was half-remembering.
--
John Cowan http://www.ccil.org/~cowan cowan(a)ccil.org
You are a child of the universe no less than the trees and all other acyclic
graphs; you have a right to be here. --DeXiderata by Sean McGrath
7:25 a.m.
New subject: Command-line options
On Sat, 26 Mar 2016, Ronald Natalie wrote:
The other fun character set was the old UNIVAC
Fielddata. There were no
non printing characters and in fact not even a null value (the 0 value
was called master space and printed as @).
What was the character set used by CDC? 60-bit words, of 10 6-bit
"characters",
as I recall... I thought it was Fielddata, but you're saying that that's
Univac's.
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."
7:50 a.m.
New subject: Command-line options
On Sat, Mar 26, 2016 at 6:25 PM, Dave Horsfall <dave(a)horsfall.org> wrote:
On Sat, 26 Mar 2016, Ronald Natalie wrote:
<I used SCOPE and NOS/BE in the mid-70s, much has been lost....>
I seem to recall both 6 bit and a larger field that handled upper/lower
case; I have no recollection of the names of the encoding. I do distinctly
remember that for the six bit set, 0 was used for both ':' and
end-of-string; trailing colons on a line would disappear.
-- Charles
The other fun character set was the old UNIVAC
Fielddata. There were no
non printing characters and in fact not even a null value (the 0 value
was called master space and printed as @).
What was the character set used by CDC? 60-bit words, of 10 6-bit
"characters",
as I recall... I thought it was Fielddata, but you're saying that that's
Univac's.
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."
8:01 a.m.
New subject: Command-line options
On Sunday, 27 March 2016 at 12:25:05 +1100, Dave Horsfall wrote:
On Sat, 26 Mar 2016, Ronald Natalie wrote:
All octal from here on.
CDC had several different character sets, most called BCD. They were
unlike Fieldata, which in fact bore some resemblance to ASCII (letters
starting @ABC.. from 0 (or 40 in ASCII), digits starting at 60, ...)
In 7600 BCD, ABC started at 21 (internal) or 61 (external), and digits
started at 00, though in the external form 0 was out of line at 12.
The 3200 system had different coding again; digits were XS3 starting
at about 53.
As if that wasn't enough, the code table I'm looking at right now
(7600) has something called ASCII SUBSET with (upper case) letters
starting at 41 and digits starting at 20. No idea why they called it
ASCII.
Isn't it wonderful that we no longer have issues with character
representation?
Greg
--
Sent from my desktop computer.
Finger grog(a)FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed. If your Microsoft MUA reports
problems, please read http://tinyurl.com/broken-mua
The other fun character set was the old UNIVAC
Fielddata. There were no
non printing characters and in fact not even a null value (the 0 value
was called master space and printed as @).
What was the character set used by CDC? 60-bit words, of 10 6-bit
"characters", as I recall... I thought it was Fielddata, but you're
saying that that's Univac's. 
12:18 p.m.
New subject: Command-line options
On Sat, Mar 26, 2016, at 22:01, Greg 'groggy' Lehey wrote:
All octal from here on.
CDC had several different character sets, most called BCD. They were
unlike Fieldata, which in fact bore some resemblance to ASCII (letters
starting @ABC.. from 0 (or 40 in ASCII), digits starting at 60, ...)
Wikipedia mentions one called "CDC display code" that went :ABC..., then
the digits followed after Z.
Also, according to Wikipedia, Fieldata was a seven-bit code with A at
006 (putting Z at 037) - it wasn't ASCII-like at all, except for having
the letters in a continuous run.
In 7600 BCD, ABC started at 21 (internal) or 61 (external), and digits
started at 00, though in the external form 0 was out of line at 12.
The 3200 system had different coding again; digits were XS3 starting
at about 53.
As if that wasn't enough, the code table I'm looking at right now
(7600) has something called ASCII SUBSET with (upper case) letters
starting at 41 and digits starting at 20. No idea why they called it
ASCII.
That sounds like ECMA-1. Does it start off "sp HT LF VT FF CR SO SI ( )"
from 00?
http://web.archive.org/web/20070407200421/http://homepages.cwi.nl/~dik/engl…
mentions it as an "ISO 6 bit"
12:57 p.m.
New subject: Command-line options
On Sunday, 27 March 2016 at 2:18:33 -0400, Random832 wrote:
On Sat, Mar 26, 2016, at 22:01, Greg
'groggy' Lehey wrote:
Ah, right. That was on my table too, but I didn't understand it.
All octal from here on.
CDC had several different character sets, most called BCD. They were
unlike Fieldata, which in fact bore some resemblance to ASCII (letters
starting @ABC.. from 0 (or 40 in ASCII), digits starting at 60, ...)
Wikipedia mentions one called "CDC display code" that went :ABC..., then
the digits followed after Z. Also, according to Wikipedia, Fieldata was a seven-bit
code
Yes, I saw that too. As used on the big UNIVACs, only the low-order 6
bits were used. I note that the upper 64 characters include control
characters.
with A at 006 (putting Z at 037) it wasn't
ASCII-like at all, except
for having the letters in a continuous run.
Hmm. Somewhere I read a different version where the A followed
directly after the @. I stand corrected.
Greg
--
Sent from my desktop computer.
Finger grog(a)FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed. If your Microsoft MUA reports
problems, please read http://tinyurl.com/broken-mua
28 Mar
28 Mar
1:38 a.m.
New subject: Command-line options
On Sun, 27 Mar 2016, Random832 wrote:
Wikipedia mentions one called "CDC display
code" that went :ABC..., then
the digits followed after Z.
Display code - that's the one I was after. I wonder if the digits were
sequenced like the console i.e. 0123456789? Really irritating... (Yes, I
was a volunteer operator for the Cyber 72.)
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."
27 Mar
27 Mar
7:35 a.m.
New subject: Command-line options
On Saturday, 26 March 2016 at 16:54:48 -0400, Ronald Natalie wrote:
The other fun character set was the old UNIVAC
Fielddata. There
were no non printing characters and in fact not even a null value
(the 0 value was called master space and printed as @).
Fieldata (one D) wasn't alone there. With only 6 bits, you couldn't
afford to have non-printing characters. All 6 bit character sets I've
seen used all combinations (and why not, since control sequences were
out of band).
Greg
--
Sent from my desktop computer.
Finger grog(a)FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed. If your Microsoft MUA reports
problems, please read http://tinyurl.com/broken-mua
26 Mar
26 Mar
9:54 a.m.
On Friday, 25 March 2016 at 17:43:08 +0300, Aharon Robbins wrote:
...
I certainly think there's some truth to this idea; longer command
names and especially GNU style long options didn't appear until the
video terminal era when terminals were faster (9600 or 19200 baud!)
and much less physically demanding to use. How MUCH correlation is
there, I don't claim to know, but I think there's definitely some.
Certainly, but the question is whether it's enough to imply causality.
I am a very fast typer, but when we got our Tandem machines back in
1977, we discovered that the shell was called COMINT and the editor
was called EDIT. Too long for my liking, so I shortened them to C and
E respectively, much to the disgust of the field technicians. This
was long before I was exposed to Unix, and we were really happy with
our 9600 bps ADM-2s, so much faster than the IBM 3270s we had been
using on the /370.
Even now I tend to shorten file names. And I suspect I'm not the only
person who hates these excessively long
--options-that-could-have-been-written-more-succinctly. Probably it's
at least partially a mentality issue.
Greg
--
Sent from my desktop computer.
Finger grog(a)FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed. If your Microsoft MUA reports
problems, please read http://tinyurl.com/broken-mua
10:30 a.m.
On Sat, 26 Mar 2016, Greg 'groggy' Lehey wrote:
Even now I tend to shorten file names. And I suspect
I'm not the only
person who hates these excessively long
--options-that-could-have-been-written-more-succinctly. Probably it's
at least partially a mentality issue.
I still like one-letter switches, and my programs sometimes use tons upon
tons of them.
Even well into the days of tab completion, I still often keep my filenames
down to 8 characters or less plus extension, which leaves people wondering
what the heck "L34-01.MP4" is. (spoiler: "Lupin the 3rd, Part IV, Episode
1")
That said, just yesterday I was wondering what the heck "TANGALA.BAS" on
my hard drive was. (It was a TANdy 1000 program that played the startup
jingle from GALAga.)
-uso.
11:44 a.m.
On Saturday, 26 March 2016 at 0:30:42 -0400, Steve Nickolas wrote:
That said, just yesterday I was wondering what the heck
"TANGALA.BAS" on my hard drive was. (It was a TANdy 1000 program
that played the startup jingle from GALAga.)
http://xkcd.com/1360/
Greg
--
Sent from my desktop computer.
Finger grog(a)FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed. If your Microsoft MUA reports
problems, please read http://tinyurl.com/broken-mua
2:33 p.m.
On Sat, 26 Mar 2016, Greg 'groggy' Lehey wrote:
On Saturday, 26 March 2016 at 0:30:42 -0400, Steve
Nickolas wrote:
Too true. And that's why I have 5 nearly full multi-terabyte hard drives.
-uso.
That said, just yesterday I was wondering what the heck
"TANGALA.BAS" on my hard drive was. (It was a TANdy 1000 program
that played the startup jingle from GALAga.)
http://xkcd.com/1360/
3186
days inactive
3193
days old
23 comments
13 participants
participants (13)
-
Aharon Robbins -
Charles Anthony -
Clem Cole -
Dave Horsfall -
Diomidis Spinellis -
Greg 'groggy' Lehey -
Jaap Akkerhuis -
John Cowan -
Random832 -
Ronald Natalie -
scj＠yaccman.com -
Steve Nickolas -
Warren Toomey