[TUHS] Is the Teletype the unsung hero of Unix?

[TUHS] Is the Teletype the unsung hero of Unix?

[Aharon Robbins]

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

[TUHS] Is the Teletype the unsung hero of Unix?

[Jaap Akkerhuis]

> <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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160325/f94b33fa/attachment.sig>

[TUHS] Is the Teletype the unsung hero of Unix?

[Diomidis Spinellis]

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

[TUHS] Is the Teletype the unsung hero of Unix?

[scj]

> 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
>
>
...  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

[TUHS] Is the Teletype the unsung hero of Unix?

[Dave Horsfall]

On Mon, 28 Mar 2016, scj at 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."

[TUHS] Is the Teletype the unsung hero of Unix?

[Greg 'groggy' Lehey]

On Saturday,  2 April 2016 at  1:06:58 +1100, Dave Horsfall wrote:
> On Mon, 28 Mar 2016, scj at 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.

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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160402/7fb82dc3/attachment.sig>

[TUHS] Command-line options

[Warren Toomey]

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

[TUHS] Command-line options

[Greg 'groggy' Lehey]

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:
>> 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.

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.

> 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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160326/f4b43ad2/attachment.sig>

[TUHS] Command-line options

[John Cowan]

Greg 'groggy' Lehey scripsit:

> > 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.

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.

> 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 at 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

[TUHS] Command-line options

[Charles Anthony]

On Fri, Mar 25, 2016 at 7:10 PM, John Cowan <cowan at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160325/f573bef7/attachment.html>

[TUHS] Command-line options

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1595 bytes --]

On Fri, Mar 25, 2016 at 11:09 PM, Charles Anthony <
charles.unix.pro at 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​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160326/15bef175/attachment-0001.html>

[TUHS] Command-line options

[Ronald Natalie]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 652 bytes --]

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 @).


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2284 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160326/5790c88f/attachment.bin>

[TUHS] Command-line options

[John Cowan]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1201 bytes --]

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 at 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

[TUHS] Command-line options

[Dave Horsfall]

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."

[TUHS] Command-line options

[Charles Anthony]

On Sat, Mar 26, 2016 at 6:25 PM, Dave Horsfall <dave at horsfall.org> wrote:

> 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.
>
>
<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


>
> --
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
> suffer."
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160326/121ae602/attachment-0001.html>

[TUHS] Command-line options

[Greg 'groggy' Lehey]

On Sunday, 27 March 2016 at 12:25:05 +1100, Dave Horsfall wrote:
> 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.

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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160327/24df03cd/attachment.sig>

[TUHS] Command-line options

[Random832]

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/english/codes/stand.html
mentions it as an "ISO 6 bit"

[TUHS] Command-line options

[Greg 'groggy' Lehey]

On Sunday, 27 March 2016 at  2:18:33 -0400, Random832 wrote:
> 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.

Ah, right.  That was on my table too, but I didn't understand it.

> 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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160327/dcb1246c/attachment.sig>

[TUHS] Command-line options

[Dave Horsfall]

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."

[TUHS] Command-line options

[Greg 'groggy' Lehey]

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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160327/d1ff4144/attachment.sig>

[TUHS] Is the Teletype the unsung hero of Unix?

[Greg 'groggy' Lehey]

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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160326/b28eea17/attachment.sig>

[TUHS] Is the Teletype the unsung hero of Unix?

[Steve Nickolas]

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.

[TUHS] Is the Teletype the unsung hero of Unix?

[Greg 'groggy' Lehey]

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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160326/fbbe3d3b/attachment.sig>

[TUHS] Is the Teletype the unsung hero of Unix?

[Steve Nickolas]

On Sat, 26 Mar 2016, Greg 'groggy' Lehey wrote:

> 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/

Too true.  And that's why I have 5 nearly full multi-terabyte hard drives.

-uso.

[TUHS] Is the Teletype the unsung hero of Unix?

[Johnny Billquist]

On 2016-04-02 04:00, Greg 'groggy' Lehey <grog at lemis.com> wrote:

> On Saturday,  2 April 2016 at  1:06:58 +1100, Dave Horsfall wrote:
>> On Mon, 28 Mar 2016, scj at 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.
>
> I was thinking more of the RIM loader on the PDP-8.  16 words or 24
> bytes.

Bah! The RK8E bootloader for OS/8: 2 words... :-)

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

[TUHS] Is the Teletype the unsung hero of Unix?

[Charles Anthony]

On Fri, Apr 1, 2016 at 7:17 PM, Johnny Billquist <bqt at update.uu.se> wrote:

> On 2016-04-02 04:00, Greg 'groggy' Lehey <grog at lemis.com> wrote:
>
> On Saturday,  2 April 2016 at  1:06:58 +1100, Dave Horsfall wrote:
>>
>>> On Mon, 28 Mar 2016, scj at 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.
>>>
>>
>> I was thinking more of the RIM loader on the PDP-8.  16 words or 24
>> bytes.
>>
>
> Bah! The RK8E bootloader for OS/8: 2 words... :-)
>
>
DPS8-M: 11 36-bit words. Sad. But on the other hand, no actual CPU
instructions. All addresses and Channel Control Words and Data.

-- Charles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160401/d014f2ed/attachment.html>