[TUHS] basic tools / Universal Unix

[TUHS] basic tools / Universal Unix

[Noel Chiappa]

    > From: Dave Horsfall

    > I'm glad that I'm not the only one who remembers TECO

Urp. I wish I _didn't_ remember TECO!

"TECO Madness: A moment of convenience, a lifetime of regret." - Dave Moon

(For those who didn't catch the reference, here:

  https://www.gammalyte.com/tag/reefer-madness/

you go.)

      Noel

[TUHS] basic tools / Universal Unix

[Dario Niedermann]

Il 01/11/2017 alle 14:25, Tim Bradshaw ha scritto:

> Of course nowadays you can't rely on the thing called 'ed' being
> 'ed': I know someone who lives in ed but can't run it on some machines
> because it relies on something in /var somewhere being writable, which
> it isn't.  I've always thought that the *whole point* of ed was that
> it did not rely on vast tracts of the system actually being there,
> still less beng functional.  This person now has to edit things with
> cat (which, in some future release, will probably start assuming that
> there's a configured ipv6 interface or something, because why would
> that ever not be true?).


I recommend said person install `ed' from the Heirloom project: it's a
traditional version (with added support for UTF-8). It will even work on
modern GNU/Linux (I know for sure because it's the one I use).

http://heirloom.sourceforge.net/


-- 
Dario Niedermann.                 Also on the Internet at:

gopher://darioniedermann.it/  <>  https://www.darioniedermann.it/

[TUHS] basic tools / Universal Unix

[Larry McVoy]

On Wed, Nov 15, 2017 at 10:40:35AM -0800, Bakul Shah wrote:
> On Nov 15, 2017, at 9:12 AM, Ralph Corderoy <ralph at inputplus.co.uk> wrote:
> > 
> > Hi Noel,
> > 
> >> I've often tried to understand why some people create these incredibly
> >> complicated systems. (Looking at the voluminous LISP Machine manual set from
> >> Symbolics particularly caused this train of thought...) I think it's because
> >> they are too smart - they can remember all that stuff.
> > 
> > But smart people don't have to create complex stuff, see Unix.  :-)
> > Perhaps it's not because these designers of complexity have good recall,
> > but a mixture of the Brooks's Second-System Effect,
> > http://www.catb.org/jargon/html/S/second-system-effect.html
> > and not being constrained.
> 
> There are two kinds of smarts: people who can remember (and
> even delight in learning) a lot of complex details and add
> to it, and people who don't like to (or can't) remember a
> lot of complex details and try to remove complexity. I think
> both are needed. You don't want the first kind to design a
> system and you don't want the second kind to maintain a
> system.
> 
> But over time software complexity creeps in like disorder.
> You have to constantly try to keep things neat but often
> (you feel) you don't have time for it. "Technical debt" is
> basically the result of procrastination!

"Source code is worthless unless it is maintained"
    -- Rob Gingell, Sun

[TUHS] basic tools / Universal Unix

[Clem Cole]

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

On Wed, Nov 15, 2017 at 1:13 PM, Bakul Shah <bakul at bitblocks.com> wrote:

> Tom Almy's version,


​I'd forgotten Tom was a teco guy.   I'm not sure what happened too it, but
at some point Tom and I got the RT11 version (which was in Macro-11
assembler) running in V7 @ Tektronix ​before we had vi. Tom was the biggest
user at that point.  I was running something Phil Karn had brought to CMU
from Cornell (and I took to Tektronix) called 'fred' (friendly ed) which
had compiled in terminal support. Fred supported glass tty's; which is why
I liked it even though I knew teco & emacs from my 10's days.   Mark Bales
came up from Berkeley later that summer and brought 1BSD/2BSD with him
(that's when I learned csh and reprogrammed my fingers to the current rom
configuration).  Gosling Emacs for UNIX does not show up until we started
running Vaxen and had the address space, so at the time it was ed, fred,
vi, teco on the 11s.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171115/7d6879df/attachment.html>

[TUHS] basic tools / Universal Unix

[Bakul Shah]

On Nov 15, 2017, at 9:12 AM, Ralph Corderoy <ralph at inputplus.co.uk> wrote:
> 
> Hi Noel,
> 
>> I've often tried to understand why some people create these incredibly
>> complicated systems. (Looking at the voluminous LISP Machine manual set from
>> Symbolics particularly caused this train of thought...) I think it's because
>> they are too smart - they can remember all that stuff.
> 
> But smart people don't have to create complex stuff, see Unix.  :-)
> Perhaps it's not because these designers of complexity have good recall,
> but a mixture of the Brooks's Second-System Effect,
> http://www.catb.org/jargon/html/S/second-system-effect.html
> and not being constrained.

There are two kinds of smarts: people who can remember (and
even delight in learning) a lot of complex details and add
to it, and people who don't like to (or can't) remember a
lot of complex details and try to remove complexity. I think
both are needed. You don't want the first kind to design a
system and you don't want the second kind to maintain a
system.

But over time software complexity creeps in like disorder.
You have to constantly try to keep things neat but often
(you feel) you don't have time for it. "Technical debt" is
basically the result of procrastination!

[TUHS] basic tools / Universal Unix

[Bakul Shah]

Tom Almy's version, based on Pete Siemsen's TECO implementation
is available as a FreeBSD port. Also runs on a bunch of other
platforms. A more recent version with Blake McBride's changes
is at https://github.com/blakemcbride/TECOC. I had used TECO a
long time ago on TOPS-10 so I played with this version but it
feels completely foreign to me now:-)

> On Nov 15, 2017, at 8:48 AM, Clem Cole <clemc at ccc.com> wrote:
> 
> Teco commands were described as being 'indistinguishable from line noise.'   On 10/30/120 cps dial up lines, that was not always a good thing ;-)
> 
> One of my favorite stories of teco years ago, one of my friends was editing a teco macro and had gotten up from his terminal for a minute, his wife looked at the screen and asked him if his 2 year old has been attacking the keyboard again.
> 
> Clem
> 
> BTW:   My friend and former co-worker, Paul Cantrell wrote an excellent teco implemnentation for UNIX.   I believe if you go to his web site (copters.com) and poke around its available for download.
> 
> On Wed, Nov 15, 2017 at 11:23 AM, Arthur Krewat <krewat at kilonet.net> wrote:
> Ah, a later reply pointed out the minimalist thing. never mind ;)
> 
> 
> 
> On 11/15/2017 11:13 AM, Arthur Krewat wrote:
>> I still don't get what was so bad about TECO. 
>> 
>> *20t$$
>> <20 lines of text>
>> *fs<text to search for>$<text to replace it with>$$
>> *0lt$$ ; type current line to review what you've changed.
>> 
>> Very simple. 
>> 
>> *<fstextsearch$textreplace$>$$
>> 
>> replace all occurrences of textsearch.
>> 
>> Now, of course, searching for something like a regular expression was much harder.
>> 
>> Q-registers, all sorts of cool stuff. 
>> 
>> But then, maybe I'm talking about a later version of TECO than you all. I think I was on version 22 on TOPS-10 6.03A
>> 
>> 
>> On 11/14/2017 10:07 PM, Will Senn wrote:
>>> I wasn't going to say it earlier, but now that you've said something about it... I was thinking, thank god, ed isn't teco! :). 
>>> 
>>> On 11/14/17 8:37 PM, Warner Losh wrote:
>>>> It took me a while to realize that ed(1) is what TECO should have been.... Too much TECO trauma scared me away for far too long.... But maybe it was all the TECO macros I wrote to make the BH100 terminal useful as an editor in full screen mode....
>>>> 
>>>> Warner
>>>> 
>>>> On Tue, Nov 14, 2017 at 7:16 PM, Larry McVoy <lm at mcvoy.com> wrote:
>>>> +1.  Anyone who gets this is someone I'd work with.
>>>> 
>>>> On Tue, Nov 14, 2017 at 08:10:41PM -0600, Will Senn wrote:
>>>> > On 11/14/17 7:25 PM, Nemo wrote:
>>>> > >On 31/10/2017, Dave Horsfall <dave at horsfall.org> wrote:
>>>> > >>A previous boss insisted that all his support staff learn ED, because one
>>>> > >>day it might be the only editor available on a trashed box (you can't
>>>> > >>mount /usr etc).
>>>> > >ed man; man ed
>>>> > >
>>>> > >https://www.gnu.org/fun/jokes/ed-msg.html (Sorry -- could not resist)
>>>> > >
>>>> > >N.
>>>> >
>>>> > For all that it's the butt of jokes, ed is awesome. I didn't really
>>>> > appreciate it until vi wasn't an easy goto option anymore (v6). After
>>>> > reading Kernighan's tutorial, I kind of fell in love with it. g/re/p? Who'd
>>>> > of thunk it? ed may not be 'visual', but the entire document is editable and
>>>> > its support of regex and the global command are incredibly powerful.
>>>> > Especially, for so incredibly tiny an editor. Finally, ed is the sibling of
>>>> > sed and once I got the connection there, it opened up a whole new world of
>>>> > editing awesomeness.
>>>> >
>>>> > Will
>>>> >
>>>> > --
>>>> > GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF
>>>> 
>>>> --
>>>> ---
>>>> Larry McVoy                  lm at mcvoy.com             http://www.mcvoy.com/lm
>>>> 
>>> 
>>> -- 
>>> GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF
>>> 
>> 
> 
> 

[TUHS] basic tools / Universal Unix

[Larry McVoy]

On Wed, Nov 15, 2017 at 05:12:26PM +0000, Ralph Corderoy wrote:
> Hi Noel,
> 
> > I've often tried to understand why some people create these incredibly
> > complicated systems. (Looking at the voluminous LISP Machine manual set from
> > Symbolics particularly caused this train of thought...) I think it's because
> > they are too smart - they can remember all that stuff.
> 
> But smart people don't have to create complex stuff, see Unix.  :-)

I consider myself reasonably smart but the least smart amongst the team
I lead.  As a result, clever complicated stuff rarely got accepted because
it was too clever for me to understand.

So smart people can choose to be "dumb" and that's what I did and that's
why I can still (mostly) debug the product.

--lm

[TUHS] basic tools / Universal Unix

[Ralph Corderoy]

Hi Noel,

> I've often tried to understand why some people create these incredibly
> complicated systems. (Looking at the voluminous LISP Machine manual set from
> Symbolics particularly caused this train of thought...) I think it's because
> they are too smart - they can remember all that stuff.

But smart people don't have to create complex stuff, see Unix.  :-)
Perhaps it's not because these designers of complexity have good recall,
but a mixture of the Brooks's Second-System Effect,
http://www.catb.org/jargon/html/S/second-system-effect.html
and not being constrained.

Constraints of limited computer memory, slow CPU, money, wall-clock
time, manufacturing cost, can all help rein in a design.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy

[TUHS] basic tools / Universal Unix

[Clem Cole]

Teco commands were described as being 'indistinguishable from line noise.'
  On 10/30/120 cps dial up lines, that was not always a good thing ;-)

One of my favorite stories of teco years ago, one of my friends was editing
a teco macro and had gotten up from his terminal for a minute, his wife
looked at the screen and asked him if his 2 year old has been attacking the
keyboard again.

Clem

BTW:   My friend and former co-worker, Paul Cantrell wrote an excellent
teco implemnentation for UNIX.   I believe if you go to his web site (
copters.com) and poke around its available for download.

On Wed, Nov 15, 2017 at 11:23 AM, Arthur Krewat <krewat at kilonet.net> wrote:

> Ah, a later reply pointed out the minimalist thing. never mind ;)
>
>
>
> On 11/15/2017 11:13 AM, Arthur Krewat wrote:
>
> I still don't get what was so bad about TECO.
>
> *20t$$
> <20 lines of text>
> *fs<text to search for>$<text to replace it with>$$
> *0lt$$ ; type current line to review what you've changed.
>
> Very simple.
>
> *<fstextsearch$textreplace$>$$
>
> replace all occurrences of textsearch.
>
> Now, of course, searching for something like a regular expression was much
> harder.
>
> Q-registers, all sorts of cool stuff.
>
> But then, maybe I'm talking about a later version of TECO than you all. I
> think I was on version 22 on TOPS-10 6.03A
>
>
> On 11/14/2017 10:07 PM, Will Senn wrote:
>
> I wasn't going to say it earlier, but now that you've said something about
> it... I was thinking, thank god, ed isn't teco! :).
>
> On 11/14/17 8:37 PM, Warner Losh wrote:
>
> It took me a while to realize that ed(1) is what TECO should have been....
> Too much TECO trauma scared me away for far too long.... But maybe it was
> all the TECO macros I wrote to make the BH100 terminal useful as an editor
> in full screen mode....
>
> Warner
>
> On Tue, Nov 14, 2017 at 7:16 PM, Larry McVoy <lm at mcvoy.com> wrote:
>
>> +1.  Anyone who gets this is someone I'd work with.
>>
>> On Tue, Nov 14, 2017 at 08:10:41PM -0600, Will Senn wrote:
>> > On 11/14/17 7:25 PM, Nemo wrote:
>> > >On 31/10/2017, Dave Horsfall <dave at horsfall.org> wrote:
>> > >>A previous boss insisted that all his support staff learn ED, because
>> one
>> > >>day it might be the only editor available on a trashed box (you can't
>> > >>mount /usr etc).
>> > >ed man; man ed
>> > >
>> > >https://www.gnu.org/fun/jokes/ed-msg.html (Sorry -- could not resist)
>> > >
>> > >N.
>> >
>> > For all that it's the butt of jokes, ed is awesome. I didn't really
>> > appreciate it until vi wasn't an easy goto option anymore (v6). After
>> > reading Kernighan's tutorial, I kind of fell in love with it. g/re/p?
>> Who'd
>> > of thunk it? ed may not be 'visual', but the entire document is
>> editable and
>> > its support of regex and the global command are incredibly powerful.
>> > Especially, for so incredibly tiny an editor. Finally, ed is the
>> sibling of
>> > sed and once I got the connection there, it opened up a whole new world
>> of
>> > editing awesomeness.
>> >
>> > Will
>> >
>> > --
>> > GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF
>>
>> --
>> ---
>> Larry McVoy                  lm at mcvoy.com
>> http://www.mcvoy.com/lm
>>
>
>
> --
> GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171115/a03296d7/attachment.html>

[TUHS] basic tools / Universal Unix

[Arthur Krewat]

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

Ah, a later reply pointed out the minimalist thing. never mind ;)


On 11/15/2017 11:13 AM, Arthur Krewat wrote:
> I still don't get what was so bad about TECO.
>
> *20t$$
> <20 lines of text>
> *fs<text to search for>$<text to replace it with>$$
> *0lt$$ ; type current line to review what you've changed.
>
> Very simple.
>
> *<fstextsearch$textreplace$>$$
>
> replace all occurrences of textsearch.
>
> Now, of course, searching for something like a regular expression was 
> much harder.
>
> Q-registers, all sorts of cool stuff.
>
> But then, maybe I'm talking about a later version of TECO than you 
> all. I think I was on version 22 on TOPS-10 6.03A
>
>
> On 11/14/2017 10:07 PM, Will Senn wrote:
>> I wasn't going to say it earlier, but now that you've said something 
>> about it... I was thinking, thank god, ed isn't teco! :).
>>
>> On 11/14/17 8:37 PM, Warner Losh wrote:
>>> It took me a while to realize that ed(1) is what TECO should have 
>>> been.... Too much TECO trauma scared me away for far too long.... 
>>> But maybe it was all the TECO macros I wrote to make the BH100 
>>> terminal useful as an editor in full screen mode....
>>>
>>> Warner
>>>
>>> On Tue, Nov 14, 2017 at 7:16 PM, Larry McVoy <lm at mcvoy.com 
>>> <mailto:lm at mcvoy.com>> wrote:
>>>
>>>     +1. Anyone who gets this is someone I'd work with.
>>>
>>>     On Tue, Nov 14, 2017 at 08:10:41PM -0600, Will Senn wrote:
>>>     > On 11/14/17 7:25 PM, Nemo wrote:
>>>     > >On 31/10/2017, Dave Horsfall <dave at horsfall.org
>>>     <mailto:dave at horsfall.org>> wrote:
>>>     > >>A previous boss insisted that all his support staff learn
>>>     ED, because one
>>>     > >>day it might be the only editor available on a trashed box
>>>     (you can't
>>>     > >>mount /usr etc).
>>>     > >ed man; man ed
>>>     > >
>>>     > >https://www.gnu.org/fun/jokes/ed-msg.html
>>>     <https://www.gnu.org/fun/jokes/ed-msg.html> (Sorry -- could not
>>>     resist)
>>>     > >
>>>     > >N.
>>>     >
>>>     > For all that it's the butt of jokes, ed is awesome. I didn't
>>>     really
>>>     > appreciate it until vi wasn't an easy goto option anymore
>>>     (v6). After
>>>     > reading Kernighan's tutorial, I kind of fell in love with it.
>>>     g/re/p? Who'd
>>>     > of thunk it? ed may not be 'visual', but the entire document
>>>     is editable and
>>>     > its support of regex and the global command are incredibly
>>>     powerful.
>>>     > Especially, for so incredibly tiny an editor. Finally, ed is
>>>     the sibling of
>>>     > sed and once I got the connection there, it opened up a whole
>>>     new world of
>>>     > editing awesomeness.
>>>     >
>>>     > Will
>>>     >
>>>     > --
>>>     > GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF
>>>
>>>     --
>>>     ---
>>>     Larry McVoy                  lm at mcvoy.com <http://mcvoy.com>
>>>     http://www.mcvoy.com/lm
>>>
>>>
>>
>> -- 
>> GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171115/cb1b5fa9/attachment-0001.html>

[TUHS] basic tools / Universal Unix

[Arthur Krewat]

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

I still don't get what was so bad about TECO.

*20t$$
<20 lines of text>
*fs<text to search for>$<text to replace it with>$$
*0lt$$ ; type current line to review what you've changed.

Very simple.

*<fstextsearch$textreplace$>$$

replace all occurrences of textsearch.

Now, of course, searching for something like a regular expression was 
much harder.

Q-registers, all sorts of cool stuff.

But then, maybe I'm talking about a later version of TECO than you all. 
I think I was on version 22 on TOPS-10 6.03A


On 11/14/2017 10:07 PM, Will Senn wrote:
> I wasn't going to say it earlier, but now that you've said something 
> about it... I was thinking, thank god, ed isn't teco! :).
>
> On 11/14/17 8:37 PM, Warner Losh wrote:
>> It took me a while to realize that ed(1) is what TECO should have 
>> been.... Too much TECO trauma scared me away for far too long.... But 
>> maybe it was all the TECO macros I wrote to make the BH100 terminal 
>> useful as an editor in full screen mode....
>>
>> Warner
>>
>> On Tue, Nov 14, 2017 at 7:16 PM, Larry McVoy <lm at mcvoy.com 
>> <mailto:lm at mcvoy.com>> wrote:
>>
>>     +1. Anyone who gets this is someone I'd work with.
>>
>>     On Tue, Nov 14, 2017 at 08:10:41PM -0600, Will Senn wrote:
>>     > On 11/14/17 7:25 PM, Nemo wrote:
>>     > >On 31/10/2017, Dave Horsfall <dave at horsfall.org
>>     <mailto:dave at horsfall.org>> wrote:
>>     > >>A previous boss insisted that all his support staff learn ED,
>>     because one
>>     > >>day it might be the only editor available on a trashed box
>>     (you can't
>>     > >>mount /usr etc).
>>     > >ed man; man ed
>>     > >
>>     > >https://www.gnu.org/fun/jokes/ed-msg.html
>>     <https://www.gnu.org/fun/jokes/ed-msg.html> (Sorry -- could not
>>     resist)
>>     > >
>>     > >N.
>>     >
>>     > For all that it's the butt of jokes, ed is awesome. I didn't really
>>     > appreciate it until vi wasn't an easy goto option anymore (v6).
>>     After
>>     > reading Kernighan's tutorial, I kind of fell in love with it.
>>     g/re/p? Who'd
>>     > of thunk it? ed may not be 'visual', but the entire document is
>>     editable and
>>     > its support of regex and the global command are incredibly
>>     powerful.
>>     > Especially, for so incredibly tiny an editor. Finally, ed is
>>     the sibling of
>>     > sed and once I got the connection there, it opened up a whole
>>     new world of
>>     > editing awesomeness.
>>     >
>>     > Will
>>     >
>>     > --
>>     > GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF
>>
>>     --
>>     ---
>>     Larry McVoy                  lm at mcvoy.com <http://mcvoy.com>
>>     http://www.mcvoy.com/lm
>>
>>
>
> -- 
> GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF

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

[TUHS] basic tools / Universal Unix

[Noel Chiappa]

    > From: Andy Kosela

    > That is why MIT and Bell Labs represented two very different cultures.

Oi! Not _everyone_ at MIT follows the "so complicated that there are no
obvious deficiencies" approach (to quote Hoare's wonderful aphorism from his
'Emperor's Old Clothes' Turing Award Lecture).

My personal design mantra (it's been at the top of my home page for decades)
is something I found as a footnote in Corbato and Saltzer, 'Multics: The First
Seven Years': "In anything at all, perfection has been attained, not when
there is nothing left to add, but when there is nothing left to take away..."

No doubt some people would be bemused that this should be in a Multics paper,
given the impression people have of Multics as incredibly - overly -
complicated. I'll avoid that discussion for the moment...


I've often tried to understand why some people create these incredibly
complicated systems. (Looking at the voluminous LISP Machine manual set from
Symbolics particularly caused this train of thought...) I think it's because
they are too smart - they can remember all that stuff.

Maybe my brain isn't like that (or perhaps I use large parts of it for other
stuff, like Japanese woodblock prints :-), but I much prefer simpler things.
Or maybe I'm just basically lazy, and like simpler things because they are
easier...

	Noel

[TUHS] basic tools / Universal Unix

[Ralph Corderoy]

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

Will Senn wrote:
> Finally, ed is the sibling of sed

Parent.  :-)

Something I learned today was (sed's author) McMahon's method of
arranging a tournament.

    ...was originally used as a club ranking system at the New York Go
    Club.  It was then adopted for Go tournaments in Britain, and has
    since become the most popular tournament system used in Go.
        — https://en.wikipedia.org/wiki/McMahon_system_tournament

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy

[TUHS] basic tools / Universal Unix

[Andy Kosela]

On Wednesday, November 15, 2017, Warner Losh <imp at bsdimp.com> wrote:

> It took me a while to realize that ed(1) is what TECO should have been....
> Too much TECO trauma scared me away for far too long.... But maybe it was
> all the TECO macros I wrote to make the BH100 terminal useful as an editor
> in full screen mode....
>
>
TECO (and therefore Emacs) and ed(1) represent two completely opposite
views on software development and IT in general.  The one is
fanatical about minimalism and 'less is more' approach, while the other
stands for 'more is more'.

That is why MIT and Bell Labs represented two very different cultures.  In
the history of computing I have not found any other group of computer
scientists that so deeply emphasized minimalism and 'less is more' approach.

This group produced the original UNIX and C, Plan 9, and Go programming
language.  Everything else in the Unix camp including BSD, Linux or GNU was
never about minimalism as its main goals, although one can argue that in
the early years Linux kernel was small and minimal.

--Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171115/1958ea12/attachment-0001.html>

[TUHS] basic tools / Universal Unix

[Will Senn]

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

I wasn't going to say it earlier, but now that you've said something 
about it... I was thinking, thank god, ed isn't teco! :).

On 11/14/17 8:37 PM, Warner Losh wrote:
> It took me a while to realize that ed(1) is what TECO should have 
> been.... Too much TECO trauma scared me away for far too long.... But 
> maybe it was all the TECO macros I wrote to make the BH100 terminal 
> useful as an editor in full screen mode....
>
> Warner
>
> On Tue, Nov 14, 2017 at 7:16 PM, Larry McVoy <lm at mcvoy.com 
> <mailto:lm at mcvoy.com>> wrote:
>
>     +1. Anyone who gets this is someone I'd work with.
>
>     On Tue, Nov 14, 2017 at 08:10:41PM -0600, Will Senn wrote:
>     > On 11/14/17 7:25 PM, Nemo wrote:
>     > >On 31/10/2017, Dave Horsfall <dave at horsfall.org
>     <mailto:dave at horsfall.org>> wrote:
>     > >>A previous boss insisted that all his support staff learn ED,
>     because one
>     > >>day it might be the only editor available on a trashed box
>     (you can't
>     > >>mount /usr etc).
>     > >ed man; man ed
>     > >
>     > >https://www.gnu.org/fun/jokes/ed-msg.html
>     <https://www.gnu.org/fun/jokes/ed-msg.html> (Sorry -- could not
>     resist)
>     > >
>     > >N.
>     >
>     > For all that it's the butt of jokes, ed is awesome. I didn't really
>     > appreciate it until vi wasn't an easy goto option anymore (v6).
>     After
>     > reading Kernighan's tutorial, I kind of fell in love with it.
>     g/re/p? Who'd
>     > of thunk it? ed may not be 'visual', but the entire document is
>     editable and
>     > its support of regex and the global command are incredibly powerful.
>     > Especially, for so incredibly tiny an editor. Finally, ed is the
>     sibling of
>     > sed and once I got the connection there, it opened up a whole
>     new world of
>     > editing awesomeness.
>     >
>     > Will
>     >
>     > --
>     > GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF
>
>     --
>     ---
>     Larry McVoy                  lm at mcvoy.com <http://mcvoy.com>
>     http://www.mcvoy.com/lm
>
>

-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171114/76d68798/attachment.html>

[TUHS] basic tools / Universal Unix

[Warner Losh]

It took me a while to realize that ed(1) is what TECO should have been....
Too much TECO trauma scared me away for far too long.... But maybe it was
all the TECO macros I wrote to make the BH100 terminal useful as an editor
in full screen mode....

Warner

On Tue, Nov 14, 2017 at 7:16 PM, Larry McVoy <lm at mcvoy.com> wrote:

> +1.  Anyone who gets this is someone I'd work with.
>
> On Tue, Nov 14, 2017 at 08:10:41PM -0600, Will Senn wrote:
> > On 11/14/17 7:25 PM, Nemo wrote:
> > >On 31/10/2017, Dave Horsfall <dave at horsfall.org> wrote:
> > >>A previous boss insisted that all his support staff learn ED, because
> one
> > >>day it might be the only editor available on a trashed box (you can't
> > >>mount /usr etc).
> > >ed man; man ed
> > >
> > >https://www.gnu.org/fun/jokes/ed-msg.html (Sorry -- could not resist)
> > >
> > >N.
> >
> > For all that it's the butt of jokes, ed is awesome. I didn't really
> > appreciate it until vi wasn't an easy goto option anymore (v6). After
> > reading Kernighan's tutorial, I kind of fell in love with it. g/re/p?
> Who'd
> > of thunk it? ed may not be 'visual', but the entire document is editable
> and
> > its support of regex and the global command are incredibly powerful.
> > Especially, for so incredibly tiny an editor. Finally, ed is the sibling
> of
> > sed and once I got the connection there, it opened up a whole new world
> of
> > editing awesomeness.
> >
> > Will
> >
> > --
> > GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF
>
> --
> ---
> Larry McVoy                  lm at mcvoy.com
> http://www.mcvoy.com/lm
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171114/1c998140/attachment.html>

[TUHS] basic tools / Universal Unix

[Larry McVoy]

+1.  Anyone who gets this is someone I'd work with.

On Tue, Nov 14, 2017 at 08:10:41PM -0600, Will Senn wrote:
> On 11/14/17 7:25 PM, Nemo wrote:
> >On 31/10/2017, Dave Horsfall <dave at horsfall.org> wrote:
> >>A previous boss insisted that all his support staff learn ED, because one
> >>day it might be the only editor available on a trashed box (you can't
> >>mount /usr etc).
> >ed man; man ed
> >
> >https://www.gnu.org/fun/jokes/ed-msg.html (Sorry -- could not resist)
> >
> >N.
> 
> For all that it's the butt of jokes, ed is awesome. I didn't really
> appreciate it until vi wasn't an easy goto option anymore (v6). After
> reading Kernighan's tutorial, I kind of fell in love with it. g/re/p? Who'd
> of thunk it? ed may not be 'visual', but the entire document is editable and
> its support of regex and the global command are incredibly powerful.
> Especially, for so incredibly tiny an editor. Finally, ed is the sibling of
> sed and once I got the connection there, it opened up a whole new world of
> editing awesomeness.
> 
> Will
> 
> -- 
> GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

[TUHS] basic tools / Universal Unix

[Will Senn]

On 11/14/17 7:25 PM, Nemo wrote:
> On 31/10/2017, Dave Horsfall <dave at horsfall.org> wrote:
>> A previous boss insisted that all his support staff learn ED, because one
>> day it might be the only editor available on a trashed box (you can't
>> mount /usr etc).
> ed man; man ed
>
> https://www.gnu.org/fun/jokes/ed-msg.html (Sorry -- could not resist)
>
> N.

For all that it's the butt of jokes, ed is awesome. I didn't really 
appreciate it until vi wasn't an easy goto option anymore (v6). After 
reading Kernighan's tutorial, I kind of fell in love with it. g/re/p? 
Who'd of thunk it? ed may not be 'visual', but the entire document is 
editable and its support of regex and the global command are incredibly 
powerful. Especially, for so incredibly tiny an editor. Finally, ed is 
the sibling of sed and once I got the connection there, it opened up a 
whole new world of editing awesomeness.

Will

-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF

[TUHS] basic tools / Universal Unix

[Nemo]

On 31/10/2017, Dave Horsfall <dave at horsfall.org> wrote:
> A previous boss insisted that all his support staff learn ED, because one
> day it might be the only editor available on a trashed box (you can't
> mount /usr etc).

ed man; man ed

https://www.gnu.org/fun/jokes/ed-msg.html (Sorry -- could not resist)

N.

[TUHS] basic tools / Universal Unix

[Grant Taylor]

On 11/01/2017 04:51 PM, Norman Wilson wrote:
> Or, if you have moved beyond the era of simulated glass 
> teletypes on graphics screens, you could do the editing 
> in the terminal (program).

Maybe it's my naivety, but I can't visualize the workflow using 
something else.  (I briefly tried finding videos to see it, but failed.)

> It's a real shame the mux/9term way of doing things never 
> caught on.  I suppose it is because so many people are 
> wedded to programs that require cursor addressing; I'm 
> glad I never succumbed to that.

I've had people tell me things about 9term, but I can't fathom what 
using it would be like.

> I use ed (or its cousin qed a la Toronto) for simple stuff. 
>  Mostly I'll use the traditional commands, but sometimes 
> I will, in mux/9term style, print a line with p, type 
> c, edit the line on the screen, pick it up and send it, 
> type . return.

What do you mean by "pick it up" and "send it"?

Will you please elaborate on what your day to day process (using 9term's 
editing ability) is like?

> And of course I can do that sort of thing with any program, 
> whether or not it is compiled with some magic library.
> 
> All this is something of a matter of taste, but I have 
> sometimes amazed (in a good way) my colleagues with it.

:-)



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3717 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171102/1a9e1daa/attachment.bin>

[TUHS] basic tools / Universal Unix

[Paul Winalski]

On 10/30/17, Dave Horsfall <dave at horsfall.org> wrote:
>
> I'm glad that I'm not the only one who remembers TECO; a fun game was to
> type your name at it to see what it did.
>
Stan Rabinowitz once asked a question in DEC's Trivia NOTES
conference:  "What do these two-character sequences have in common?"
There followed four sets of two special characters.  The answer was
that those were the only two-character sequences that were NOT valid
TECO commands.

-Paul W.

[TUHS] basic tools / Universal Unix

[Ralph Corderoy]

Hi Arnold,

> I don't think I understand what you're getting at. It's been decades,
> I think, since I last saw / used open mode, which is what I thought
> you wanted, so I think I'm confused.

Sorry if I wasn't clear.  I miss open mode as vim doesn't have it, and
I'd sometimes find it useful.

Separately, I use ed regularly, and have though about its `compose a
command, submit it', model being extended to commands that act upon a
cursor that's within the line, just as `.' is the line within the file.
I don't mean readline editing of the command, nor of the current line in
the file.  More what one might see on the RHS of `:map Q ...', but in
the style of ed.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy

[TUHS] basic tools / Universal Unix

[Chet Ramey]

On 11/1/17 4:37 PM, arnold at skeeve.com wrote:
> Bakul Shah <bakul at bitblocks.com> wrote:
> 
>> I think what Ralph wants is something like "LINES=1 vi"
>> but without clearing the screen so that commands that
>> are cursor relative can work. rlwrap and readline don't
>> edit the current line in the file, only the command input.
> 
> OK, that I can understand.  It's ages since I played with
> readline, but I think you can preload the buffer it works on
> (bash does that, no?) so ed + readline could be made to work
> that way.

Yes, you can set a startup hook to preload the buffer contents. Bash
uses that for `read -ei'.


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet at case.edu    http://cnswww.cns.cwru.edu/~chet/

[TUHS] basic tools / Universal Unix

[Lyndon Nerenberg]

> On Nov 1, 2017, at 3:51 PM, Norman Wilson <norman at oclsc.org> wrote:
> 
> I use ed (or its cousin qed a la Toronto) for simple stuff.
> Mostly I'll use the traditional commands, but sometimes
> I will, in mux/9term style, print a line with p, type
> c, edit the line on the screen, pick it up and send it,
> type . return.
> 
> And of course I can do that sort of thing with any program,
> whether or not it is compiled with some magic library.
> 
> All this is something of a matter of taste, but I have
> sometimes amazed (in a good way) my colleagues with it.

If 9term's "hold" mode had a (built in) way to do acme's "|fmt" I would achieve a state of bliss.  Who needs text editors.

[TUHS] basic tools / Universal Unix

[Norman Wilson]

Arnold:

> OK, that I can understand.  It's ages since I played with
> readline, but I think you can preload the buffer it works on
> (bash does that, no?) so ed + readline could be made to work
> that way.

====

Or, if you have moved beyond the era of simulated glass
teletypes on graphics screens, you could do the editing
in the terminal (program).

It's a real shame the mux/9term way of doing things never
caught on.  I suppose it is because so many people are
wedded to programs that require cursor addressing; I'm
glad I never succumbed to that.

I use ed (or its cousin qed a la Toronto) for simple stuff.
Mostly I'll use the traditional commands, but sometimes
I will, in mux/9term style, print a line with p, type
c, edit the line on the screen, pick it up and send it,
type . return.

And of course I can do that sort of thing with any program,
whether or not it is compiled with some magic library.

All this is something of a matter of taste, but I have
sometimes amazed (in a good way) my colleagues with it.

Norman Wilson
Toronto ON

[TUHS] basic tools / Universal Unix

[Bakul Shah]

On Wed, 01 Nov 2017 14:37:42 -0600 arnold at skeeve.com wrote:
arnold at skeeve.com writes:
> Bakul Shah <bakul at bitblocks.com> wrote:
> 
> > I think what Ralph wants is something like "LINES=1 vi"
> > but without clearing the screen so that commands that
> > are cursor relative can work. rlwrap and readline don't
> > edit the current line in the file, only the command input.
> 
> OK, that I can understand.  It's ages since I played with
> readline, but I think you can preload the buffer it works on
> (bash does that, no?) so ed + readline could be made to work
> that way.

Editing that way seem is bass ackwards -- probably more code
would needed to interface with readline than just implementing
it in ed. As a one line version requires just line movement
commands, there is no reason why you can't use full power of
vi through a narrow window - such as d} to delete to the end
of para and have the next line dispayed. Readline wouldn't
help there. And readline weighs in @ 28K LOC to ed's 3.5K (on
plan9 it is under 1.6K).

> I already have too many side projects on my plate, or I'd try it. :-)

Ditto!

[TUHS] basic tools / Universal Unix

[arnold]

Bakul Shah <bakul at bitblocks.com> wrote:

> I think what Ralph wants is something like "LINES=1 vi"
> but without clearing the screen so that commands that
> are cursor relative can work. rlwrap and readline don't
> edit the current line in the file, only the command input.

OK, that I can understand.  It's ages since I played with
readline, but I think you can preload the buffer it works on
(bash does that, no?) so ed + readline could be made to work
that way.

At least, I think so.

I already have too many side projects on my plate, or I'd try it. :-)

Thanks,

Arnold

[TUHS] basic tools / Universal Unix

[Bakul Shah]

> On Nov 1, 2017, at 11:06 AM, arnold at skeeve.com wrote:
> 
> Ralph Corderoy <ralph at inputplus.co.uk> wrote:
> 
>> Hi Arnold,
>> 
>>>> I've idly considered an ed that also maintained a cursor within the
>>>> line that could be used with vi-like commands.
>>> 
>>> you want an ed with a cursor, you need only take GNU ed and hook it up
>>> with GNU readline, and there you go.
>> 
>> That would allow me to edit the command I'm entering, e.g. `,n'.  What
>> I'm suggesting is the command I'm entering can manipulate the in-line
>> cursor when I press Enter to submit the command.  I don't want
>> interactive editing of lines in the file;  I know where to find that.
>> :-)
> 
> I don't think I understand what you're getting at. It's been decades,
> I think, since I last saw / used open mode, which is what I thought
> you wanted, so I think I'm confused.

I think what Ralph wants is something like "LINES=1 vi"
but without clearing the screen so that commands that
are cursor relative can work. rlwrap and readline don't
edit the current line in the file, only the command input.

[TUHS] basic tools / Universal Unix

[arnold]

Ralph Corderoy <ralph at inputplus.co.uk> wrote:

> Hi Arnold,
>
> > > I've idly considered an ed that also maintained a cursor within the
> > > line that could be used with vi-like commands.
> >
> > you want an ed with a cursor, you need only take GNU ed and hook it up
> > with GNU readline, and there you go.
>
> That would allow me to edit the command I'm entering, e.g. `,n'.  What
> I'm suggesting is the command I'm entering can manipulate the in-line
> cursor when I press Enter to submit the command.  I don't want
> interactive editing of lines in the file;  I know where to find that.
> :-)

I don't think I understand what you're getting at. It's been decades,
I think, since I last saw / used open mode, which is what I thought
you wanted, so I think I'm confused.

Oh well,

Arnold

[TUHS] basic tools / Universal Unix

[Dan Cross]

Since `ed` is line-based, one could presumably use it with `rlwrap` or
something like that.

On Wed, Nov 1, 2017 at 1:17 PM, Ralph Corderoy <ralph at inputplus.co.uk> wrote:
> Hi Arnold,
>
>> > I've idly considered an ed that also maintained a cursor within the
>> > line that could be used with vi-like commands.
>>
>> you want an ed with a cursor, you need only take GNU ed and hook it up
>> with GNU readline, and there you go.
>
> That would allow me to edit the command I'm entering, e.g. `,n'.  What
> I'm suggesting is the command I'm entering can manipulate the in-line
> cursor when I press Enter to submit the command.  I don't want
> interactive editing of lines in the file;  I know where to find that.
> :-)
>
>> If GNU ed doesn't already have such support.
>
> ed 1.14.2-1 here hasn't.  And I wouldn't expect its dependencies to
> grow.
>
>     $ ldd /bin/ed
>             linux-vdso.so.1 (0x00007fff215d4000)
>             libc.so.6 => /usr/lib/libc.so.6 (0x00007fd89767a000)
>             /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007fd897a31000)
>     $
>
> --
> Cheers, Ralph.
> https://plus.google.com/+RalphCorderoy

[TUHS] basic tools / Universal Unix

[Ralph Corderoy]

Hi Arnold,

> > I've idly considered an ed that also maintained a cursor within the
> > line that could be used with vi-like commands.
>
> you want an ed with a cursor, you need only take GNU ed and hook it up
> with GNU readline, and there you go.

That would allow me to edit the command I'm entering, e.g. `,n'.  What
I'm suggesting is the command I'm entering can manipulate the in-line
cursor when I press Enter to submit the command.  I don't want
interactive editing of lines in the file;  I know where to find that.
:-)

> If GNU ed doesn't already have such support.

ed 1.14.2-1 here hasn't.  And I wouldn't expect its dependencies to
grow.

    $ ldd /bin/ed
            linux-vdso.so.1 (0x00007fff215d4000)
            libc.so.6 => /usr/lib/libc.so.6 (0x00007fd89767a000)
            /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007fd897a31000)
    $

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy

[TUHS] basic tools / Universal Unix

[arnold]

Ralph Corderoy <ralph at inputplus.co.uk> wrote:

> I've idly considered an ed that also maintained a cursor within the line
> that could be used with vi-like commands.

	Are we not Hackers?  Can we not code as we wish?!?
		-- Somebody, I forget who

But seriously, you want an ed with a cursor, you need only take
GNU ed and hook it up with GNU readline, and there you go.  If
GNU ed doesn't already have such support.  Absolutely no need to
reinvent either wheel.

My two cents,

Arnold

[TUHS] basic tools / Universal Unix

[Ralph Corderoy]

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

Hi Ronald,

> On a few machines where I’m confronted with VI and no ed/emacs, I just
> use VI in “ex” mode.

One thing I miss with vim(1) is the lack of open mode, the half-way
house between ex and vi modes.  I still use ed daily when I know the
edit I want to do and have the context to work by, e.g. output from
previous commands, on the screen, that I don't want removed by a
full-screen editor.  But sometimes it would be nice to be able to `f(c%'
rather than always have to regexp the edit and vi's open mode would give
me that.

I've idly considered an ed that also maintained a cursor within the line
that could be used with vi-like commands.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy

[TUHS] basic tools / Universal Unix

[Tim Bradshaw]

> On 1 Nov 2017, at 03:23, Dave Horsfall <dave at horsfall.org> wrote:
> 
> A previous boss insisted that all his support staff learn ED, because one day it might be the only editor available on a trashed box (you can't mount /usr etc).

That's happened to me relatively recently (I know ed just well enough to get machines out of that state).

Of course nowadays you can't rely on the thing called 'ed' being 'ed': I know someone who lives in ed but can't run it on some machines because it relies on something in /var somewhere being writable, which it isn't.  I've always thought that the *whole point* of ed was that it did not rely on vast tracts of the system actually being there, still less beng functional.  This person now has to edit things with cat (which, in some future release, will probably start assuming that there's a configured ipv6 interface or something, because why would that ever not be true?).

--tim

[TUHS] basic tools / Universal Unix

[Dave Horsfall]

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

On Tue, 31 Oct 2017, Ronald Natalie wrote:

> I’m a bizarre UNIX relic.  I never learned vi.  I went from “ed” to the 
> various emacs variants (starting with Warren Montgomery’s EMACS, then 
> JOVE and UNIPRESS, and later GNU).  I used INed (a commercialization of 
> the Rand editor) but didn't particularly like that either.  My coworkers 
> for years would be amused when if I found the machine had no EMACS 
> variant, I’d just use ed.  I could be startlingly fast in ed and you do 
> learn regular expressions well if you have to do a lot of editing that 
> way.  On a few machines where I’m confronted with VI and no ed/emacs, I 
> just use VI in “ex” mode.

A previous boss insisted that all his support staff learn ED, because one 
day it might be the only editor available on a trashed box (you can't 
mount /usr etc).

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] basic tools / Universal Unix

[Norman Wilson]

I too remember TECO.  In my TOPS-10 days I was quite a whiz at it.

Then I encountered UNIX and ed, and never looked back.  Cryptic
programmability is fun, but a simple but well-chosen set of
commands including the g/v pair made me more efficient in the end.

it could just be that ed is a better fit for the shape of my brain.
C struck me similarly.

Norman Wilson
Toronto ON
(Actually in the Bay Area for a few days for LISA, in case any
UNIXtorians want to meet up.)

[TUHS] basic tools / Universal Unix

[Don Hopkins]

> On 30 Oct 2017, at 21:56, Dave Horsfall <dave at horsfall.org> wrote:
> 
> I'm glad that I'm not the only one who remembers TECO; a fun game was to type your name at it to see what it did.

A great game to play while traveling is to interpret what license plates do in TECO. 

-Don

[TUHS] basic tools / Universal Unix

[Ronald Natalie]

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

.  make love
NOT WAR?
[4K CORE]


I’m a bizarre UNIX relic.    I never learned vi.   I went from “ed” to the various emacs variants (starting with Warren Montgomery’s EMACS, then JOVE and UNIPRESS, and later GNU).     I used INed (a commercialization of the Rand editor) but didn’t particularly like that either.    My coworkers for years would be amused when if I found the machine had no EMACS variant, I’d just use ed.    I could be startlingly fast in ed and you do learn regular expressions well if you have to do a lot of editing that way.    On a few machines where I’m confronted with VI and no ed/emacs, I just use VI in “ex” mode.






> On Oct 30, 2017, at 4:56 PM, Dave Horsfall <dave at horsfall.org> wrote:
> 
> On Mon, 30 Oct 2017, Noel Chiappa wrote:
> 
>>   > Then the real definition, ending in an execution of the empty `q'.
>>   > qq/4$^Ma2^[@qq
>> 
>> Gah. That reminds me of nothing so much as TECO (may it long Rest in Peace).
> 
> I'm glad that I'm not the only one who remembers TECO; a fun game was to type your name at it to see what it did.
> 
> -- 
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] basic tools / Universal Unix

[Charles Anthony]

On Mon, Oct 30, 2017 at 7:16 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>     > From: Ralph Corderoy
>
>     > Then the real definition, ending in an execution of the empty `q'.
>     > qq/4$^Ma2^[@qq
>
> Gah. That reminds me of nothing so much as TECO (may it long Rest in
> Peace).
>
>
I've started using it again; at least until I can get vi running under
Multics.

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

[TUHS] basic tools / Universal Unix

[Dave Horsfall]

On Mon, 30 Oct 2017, Noel Chiappa wrote:

>    > Then the real definition, ending in an execution of the empty `q'.
>    > qq/4$^Ma2^[@qq
>
> Gah. That reminds me of nothing so much as TECO (may it long Rest in 
> Peace).

I'm glad that I'm not the only one who remembers TECO; a fun game was to 
type your name at it to see what it did.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] basic tools / Universal Unix

[Arthur Krewat]

Aw, I loved TECO - so much so that I wrote a version for every platform 
I used after that until I got into consulting for various different 
companies that used UNIX's of various flavors.

At some point in that transition, I learned vi. Now I wouldn't do 
without it.

The only detrimental thing about TECO to me, was that it was used to 
start off EMACS. ;)



On 10/30/2017 10:16 AM, Noel Chiappa wrote:
>      > From: Ralph Corderoy
>
>      > Then the real definition, ending in an execution of the empty `q'.
>      > qq/4$^Ma2^[@qq
>
> Gah. That reminds me of nothing so much as TECO (may it long Rest in Peace).
>
>       Noel
>

[TUHS] basic tools / Universal Unix

[Clem Cole]

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

On Mon, Oct 30, 2017 at 10:16 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>     > From: Ralph Corderoy
>
>     > Then the real definition, ending in an execution of the empty `q'.
>     > qq/4$^Ma2^[@qq
>
> Gah. That reminds me of nothing so much as TECO (may it long Rest in
> Peace).
>
​Or line noise from the acoustic coupler :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171030/ffa08289/attachment.html>

[TUHS] basic tools / Universal Unix

[Noel Chiappa]

    > From: Ralph Corderoy

    > Then the real definition, ending in an execution of the empty `q'.
    > qq/4$^Ma2^[@qq

Gah. That reminds me of nothing so much as TECO (may it long Rest in Peace).

     Noel

[TUHS] basic tools / Universal Unix

[Ralph Corderoy]

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

Hi Bakul,

> Thanks, didn't know about q.  However, nvi doesn't have q.

It's just a means of recording typing into a register.  Exactly the same
can be achieved by typing into the buffer and then yanking into the
named register, being careful to leave off the LF at the end of the line
if it's not wanted, e.g. «"qy$».

> What I was getting at is being able to define commands that can take
> one or two arguments like the bulitins, separate from any key mapping.

If `3wy' yanked three words then the macro in register `q' could start
with `y' allowing `3w at q' to pass a region to the macro, but it doesn't.
:-)  I think one's left with setting a mark, or using automatic ones set
at various times by vim, and the macro using those to know its region.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy

[TUHS] basic tools / Universal Unix

[Bakul Shah]

On Mon, 30 Oct 2017 00:55:07 -0000 Ralph Corderoy <ralph at inputplus.co.uk> wrote:
Ralph Corderoy writes:
> Hi Bakul,
> 
> Regarding vi:
> > As an example, you can map a key to do a sequence of operations but
> > you you can't then use it in conjunction with search to repeat them
> > over a range of lines.
> 
> You can use tail recursion in the macro because a failed search causes
> it to stop.  So `qqq' to start recording to register `q', and then
> instantly stop recording, clearing it.  Then the real definition, ending
> in an execution of the empty `q'.
> 
>     qq/4$^Ma2^[@qq
> 
> And finally an `@q' to kick off the recursion.

Thanks, didn't know about q. However, nvi doesn't have q.  vim
does (but I rarely ever use it so when I tried the above it
failed). What I was getting at is being able to define
commands that can take one or two arguments like the bulitins,
separate from any key mapping. You need an ability to pass and
refer to arguments as well as refer to the current context.
And to be able to operate on char/word/line/para/sections.  If
this machinery was accessible, may be even many of vi's
builtins can be implemented this way.  E.g "d}" maps to
(delete 1para), "3dd" maps to (delete 3line) and so on.

[TUHS] basic tools / Universal Unix

[Ralph Corderoy]

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

Hi Bakul,

Regarding vi:
> As an example, you can map a key to do a sequence of operations but
> you you can’t then use it in conjunction with search to repeat them
> over a range of lines.

You can use tail recursion in the macro because a failed search causes
it to stop.  So `qqq' to start recording to register `q', and then
instantly stop recording, clearing it.  Then the real definition, ending
in an execution of the empty `q'.

    qq/4$^Ma2^[@qq

And finally an `@q' to kick off the recursion.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy

[TUHS] basic tools / Universal Unix

[Steffen Nurpmeso]

Random832 <random832 at fastmail.com> wrote:
 |On Thu, Oct 19, 2017, at 10:33, Steffen Nurpmeso wrote:
 |> Random832 <random832 at fastmail.com> wrote:
 |>|On Wed, Oct 18, 2017, at 19:03, Doug McIlroy wrote:
 |>|>> But mind you, in preparation of this email i found a bug in
 |>|>> Busybox sed(1) which simply echoes nothing for the above.
 |>|> 
 |>|> I assume that * is a typo for - . If so, sed did just what
 |>|> -n tells it to--no printing except as called for by p or P.
 |>|
 |>|Or, you know, l (the letter ell). Which busybox sed appears to not
 |>|support at all, rather than somehow misapplying -n to it.
 ...
 |I think that makes this a legitimate bug[...]

I finally realized that the MUA i maintain never supported these
kind of (output character set) iconv(3) errors for the main body
of the message, even after iconv tweakings (including
a n_ICONV_IGN_NOREVERSE flag).
Thus i could fix that with credit due to Doug McIlroy and you,
and will release v14.9.5 tomorrow.
Yes, so thank you both!

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

[TUHS] basic tools / Universal Unix

[Steffen Nurpmeso]

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

Good evening everybody.

Random832 <random832 at fastmail.com> wrote:
 |On Thu, Oct 19, 2017, at 10:33, Steffen Nurpmeso wrote:
 |> Random832 <random832 at fastmail.com> wrote:
 |>|On Wed, Oct 18, 2017, at 19:03, Doug McIlroy wrote:
 |>|>> But mind you, in preparation of this email i found a bug in
 |>|>> Busybox sed(1) which simply echoes nothing for the above.
 |>|> 
 |>|> I assume that * is a typo for - . If so, sed did just what
 |>|> -n tells it to--no printing except as called for by p or P.
 |>|
 |>|Or, you know, l (the letter ell). Which busybox sed appears to not
 |>|support at all, rather than somehow misapplying -n to it.
 |> 
 |> The letter l, yes.  But it does not fail either, so it knows about
 |> it, talking version 1.27.something here.
 |
 |If you look at the source, it is in the list that is checked for
 |printing (or not) the 'unsupported command' error message, but there is
 |no actual code to handle it (and when called *without* -n, it just falls
 |through and prints once, just like if you'd had no command at all)
 |
 |https://git.busybox.net/busybox/plain/editors/sed.c?h=1_3_stable

That is true.

 |I think that makes this a legitimate bug in busybox, rather than simply
 |an artifact of being a minimal tool that doesn't aim for posix (or
 |historical unix) conformance.

Yes, it should error out or implement the stuff i think.  The way
it is is not handable.
The comments in coreutils/cat.c are postable in this thread too:

/* Rob had "cat -v" implemented as a separate applet, catv.
[That is Rob AT Landley DOT NET]
 * See "cat -v considered harmful" at
 * http://cm.bell-labs.com/cm/cs/doc/84/kp.ps.gz
[This server has been killed]
 * From USENIX Summer Conference Proceedings, 1983
 * """
 * The talk reviews reasons for UNIX's popularity and shows, using UCB cat
 * as a primary example, how UNIX has grown fat. cat isn't for printing
 * files with line numbers, it isn't for compressing multiple blank lines,
 * it's not for looking at non-printing ASCII characters, it's for
 * concatenating files.
 * We are reminded that ls isn't the place for code to break a single column
 * into multiple ones, and that mailnews shouldn't have its own more
 * processing or joke encryption code.
 * """
 *
 * I agree with the argument. Unfortunately, this ship has sailed (1983...).
 * There are dozens of Linux distros and each of them has "cat" which supports -v.
 * It's unrealistic for us to "reeducate" them to use our, incompatible way
 * to achieve "cat -v" effect. The actual effect would be "users pissed off
 * by gratuitous incompatibility".

And, indeed sailing (-vet explicitly compiled in):

  ?0[steffen at essex busybox.git]$ echo −e | cat -vet
  M-bM-^HM-^Re$

Then again, you know, i personally have problems with -vet and
think the POSIX sed variant is easier to grasp:

  ?0[steffen at essex busybox.git]$ echo −e | sed -n l
  \342\210\222e$

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

[TUHS] basic tools / Universal Unix

[Random832]

On Thu, Oct 19, 2017, at 10:33, Steffen Nurpmeso wrote:
> Random832 <random832 at fastmail.com> wrote:
>  |On Wed, Oct 18, 2017, at 19:03, Doug McIlroy wrote:
>  |>> But mind you, in preparation of this email i found a bug in
>  |>> Busybox sed(1) which simply echoes nothing for the above.
>  |> 
>  |> I assume that * is a typo for - . If so, sed did just what
>  |> -n tells it to--no printing except as called for by p or P.
>  |
>  |Or, you know, l (the letter ell). Which busybox sed appears to not
>  |support at all, rather than somehow misapplying -n to it.
> 
> The letter l, yes.  But it does not fail either, so it knows about
> it, talking version 1.27.something here.

If you look at the source, it is in the list that is checked for
printing (or not) the 'unsupported command' error message, but there is
no actual code to handle it (and when called *without* -n, it just falls
through and prints once, just like if you'd had no command at all)

https://git.busybox.net/busybox/plain/editors/sed.c?h=1_3_stable

I think that makes this a legitimate bug in busybox, rather than simply
an artifact of being a minimal tool that doesn't aim for posix (or
historical unix) conformance.

[TUHS] basic tools / Universal Unix

[Steffen Nurpmeso]

Random832 <random832 at fastmail.com> wrote:
 |On Wed, Oct 18, 2017, at 19:03, Doug McIlroy wrote:
 |>> But mind you, in preparation of this email i found a bug in
 |>> Busybox sed(1) which simply echoes nothing for the above.
 |> 
 |> I assume that * is a typo for - . If so, sed did just what
 |> -n tells it to--no printing except as called for by p or P.
 |
 |Or, you know, l (the letter ell). Which busybox sed appears to not
 |support at all, rather than somehow misapplying -n to it.

The letter l, yes.  But it does not fail either, so it knows about
it, talking version 1.27.something here.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

[TUHS] basic tools / Universal Unix

[Steffen Nurpmeso]

Doug McIlroy <doug at cs.dartmouth.edu> wrote:
 |>       sed *n l pathname
 |>
 |>   The latter also has the advantage that its output is
 |
 |>   unambiguous, whereas the output of historical cat *etv is not.
 |>
 |> But mind you, in preparation of this email i found a bug in
 |> Busybox sed(1) which simply echoes nothing for the above.
 |
 |I assume that * is a typo for - . If so, sed did just what
 |-n tells it to--no printing except as called for by p or P.

It seems to be a problem of (the PDF to text conversion and) the
musl C library environment used on this box:

  ?0[steffen at essex tmp]$ echo *e | s-hex
  00000000  e2 88 92 65 0a                                    |...e.|
  00000005
  ?0[steffen at essex tmp]$ echo *e | iconv -f utf8 -t ascii
  *e
  ?0[steffen at essex tmp]$ command -v iconv
  /usr/bin/iconv
  ?0[steffen at essex tmp]$ apk info --who-owns /usr/bin/iconv
  /usr/bin/iconv is owned by musl-utils-1.1.16-r22

And of course because of mailx's "set reply-in-same-charset"
ending up using US-ASCII.

 |And speaking of sed anticipating other tools, the inclusion
 |of "head" in v7 as a complement to "tail" was a close call
 |because head is subsumed by sed q.

The difference being that these can be implemented as shell script
wrappers around (modern) sed easily, whereas the -vet thing would
require painful awk scripting, by reading bytewise and string
comparing each of those bytes against a sprintf("%c",0.255) and
a tree of if conditions, without having tried it.
And then head and tail are self-describing, whereas -vet as
a modifier for file content c(onc)atenation i never had problems
with, but looking for that feature in a stream editor is more
obvious for the unaware.

 |Doug

Ju-hu!

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

[TUHS] basic tools / Universal Unix

[Random832]

On Wed, Oct 18, 2017, at 19:03, Doug McIlroy wrote:
> > But mind you, in preparation of this email i found a bug in
> > Busybox sed(1) which simply echoes nothing for the above.
> 
> I assume that * is a typo for - . If so, sed did just what
> -n tells it to--no printing except as called for by p or P.

Or, you know, l (the letter ell). Which busybox sed appears to not
support at all, rather than somehow misapplying -n to it.

[TUHS] basic tools / Universal Unix

[Doug McIlroy]

>       sed *n l pathname
>
>   The latter also has the advantage that its output is

>   unambiguous, whereas the output of historical cat *etv is not.
>
> But mind you, in preparation of this email i found a bug in
> Busybox sed(1) which simply echoes nothing for the above.

I assume that * is a typo for - . If so, sed did just what
-n tells it to--no printing except as called for by p or P.

And speaking of sed anticipating other tools, the inclusion
of "head" in v7 as a complement to "tail" was a close call
because head is subsumed by sed q.

Doug

[TUHS] basic tools / Universal Unix

[Steffen Nurpmeso]

Tony Finch <dot at dotat.at> wrote:
 |Dan Cross <crossd at gmail.com> wrote:
 |> This is an aside, but I must admit -- with a sense of mild shame --
 |> that the '-v' option to cat is one that I use with some regularity.
 |
 |4.4BSD has the vis(1) and unvis(1) utilities which are more principled
 |implementations of this feature (with corresponding section 3 functions).
 |It's slightly annoying being on Linux without vis and having to resort to
 |`cat -v` like some kind of savage.

Stop!  The inner circle of Unix/POSIX standard developers have
(again) shown great wisdom and have put it down black on white:

  Historical versions of the cat utility include the *e, *t, and
  *v, options which permit the ends of lines, <tab> characters,
  and invisible characters, respectively, to be rendered visible
  in the output. The standard developers omitted these options
  because they provide too fine a degree of control over what is
  made visible, and similar output can be obtained using a command
  such as:

      sed *n l pathname

  The latter also has the advantage that its output is
  unambiguous, whereas the output of historical cat *etv is not.

But mind you, in preparation of this email i found a bug in
Busybox sed(1) which simply echoes nothing for the above.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

[TUHS] basic tools / Universal Unix

[Tony Finch]

Dan Cross <crossd at gmail.com> wrote:

> This is an aside, but I must admit -- with a sense of mild shame --
> that the '-v' option to cat is one that I use with some regularity.

4.4BSD has the vis(1) and unvis(1) utilities which are more principled
implementations of this feature (with corresponding section 3 functions).
It's slightly annoying being on Linux without vis and having to resort to
`cat -v` like some kind of savage.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Malin, Hebrides: North or northwest, veering southeast, 5 to 7, occasionally
gale 8 at first in Hebrides. Moderate or rough, occasionally very rough at
first. Rain or showers. Moderate or good.

[TUHS] basic tools / Universal Unix

[Andy Kosela]

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

On Monday, October 16, 2017, Clem Cole <clemc at ccc.com> wrote:

>
>
> On Mon, Oct 16, 2017 at 12:39 PM, Jon Steinhart <jon at fourwinds.com
> <javascript:_e(%7B%7D,'cvml','jon at fourwinds.com');>> wrote:
>
>>
>> I have a similar and maybe even more extreme position.  When I was a
>> manager
>> I placed restrictions on the tools and customizations for members of my
>> team.
>> My goal was to make sure that any team member could go over to any other
>> team
>> member's desk and get stuff done.
>
>
> ​And I think this loops back to what started some of this threat.  The
> idea of a programmer with 'good taste.'
> Rob (and Brian) railed on BSD in cat -v considered harmful
> <http://harmful.cat-v.org/cat-v/> and ‘*Program Design in the UNIX
> Environment*’ (pdf version
> <http://harmful.cat-v.org/cat-v/unix_prog_design.pdf>, ps version
> <http://harmful.cat-v.org/cat-v/unix_prog_design.ps>) but the points in
> it was then and are still now, fresh:  What is it that you need to get the
> job done - to me, that is Doug's "Universal Unix" concept.
>
> When I answer questions on quora about learning Linux and other UNIX
> derivative, I still point them at their  book:   *The Unix Programming
> Environment
> <http://www.amazon.com/gp/product/013937681X?ie=UTF8&tag=catv-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=013937681X>*
>
> I would say, if the can login into the system and complete the exercises
> in UPE without having to make changes, you are pretty close to Doug's
> "Universal UNIX" environment.  And if you can use the tools, without having
> to think about them and they pretty much are what you rely upon everyday,
> you are getting close to my ideal of 'good taste.'
>
>
"The UNIX Programming Environment" is still one of my favorite books of all
times.  That is the essence of Universal Unix philosophy.

If only Linux, which is de facto standard Unix operating system these days,
would strive towards that simplicity and compatibility with this Universal
Unix instead of going systemd route -- that would make me forever happy.

--Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171016/a91d93e2/attachment.html>

[TUHS] basic tools / Universal Unix

[Bakul Shah]

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

vi editing is in my fingers by now but one unixy “good taste” I missed in
it is composability. External filters didn’t quite hit the right spot. As an
example, you can map a key to do a sequence of operations but you
you can’t then use it in conjunction with search to repeat them over a
range of lines. Eventually nvi added optional support for scripting but
full power of a general PL is not quite what I wanted. And vi didn’t have
to become another Emacs. May be an ability to define new commands,
If/while control structures, expressing its notion of objects (lines, para,
Sections etc) in this DSL and an ability use user commands just like
builtins would’ve gone a long way. Of course, the hard part is coming up
with a clear conceptual model.

> On Oct 16, 2017, at 10:52 AM, Clem Cole <clemc at ccc.com> wrote:
> 
> 
> 
>> On Mon, Oct 16, 2017 at 12:39 PM, Jon Steinhart <jon at fourwinds.com> wrote:
>> 
>> I have a similar and maybe even more extreme position.  When I was a manager
>> I placed restrictions on the tools and customizations for members of my team.
>> My goal was to make sure that any team member could go over to any other team
>> member's desk and get stuff done.  
> 
> ​And I think this loops back to what started some of this threat.  The idea of a programmer with 'good taste.'
> Rob (and Brian) railed on BSD in cat -v considered harmful and ‘Program Design in the UNIX Environment’ (pdf version, ps version) but the points in it was then and are still now, fresh:  What is it that you need to get the job done - to me, that is Doug's "Universal Unix" concept.
> 
> When I answer questions on quora about learning Linux and other UNIX derivative, I still point them at their  book:   The Unix Programming Environment 
> 
> I would say, if the can login into the system and complete the exercises in UPE without having to make changes, you are pretty close to Doug's "Universal UNIX" environment.  And if you can use the tools, without having to think about them and they pretty much are what you rely upon everyday, you are getting close to my ideal of 'good taste.' 
> 
> Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171016/b313671b/attachment-0001.html>

[TUHS] basic tools / Universal Unix

[Dan Cross]

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

On Mon, Oct 16, 2017 at 1:52 PM, Clem Cole <clemc at ccc.com> wrote:
> On Mon, Oct 16, 2017 at 12:39 PM, Jon Steinhart <jon at fourwinds.com> wrote:
>> I have a similar and maybe even more extreme position.  When I was a
>> manager
>> I placed restrictions on the tools and customizations for members of my
>> team.
>> My goal was to make sure that any team member could go over to any other
>> team
>> member's desk and get stuff done.
>
>
> And I think this loops back to what started some of this threat.  The idea
> of a programmer with 'good taste.'
> Rob (and Brian) railed on BSD in cat -v considered harmful and ‘Program
> Design in the UNIX Environment’ (pdf version, ps version) but the points in
> it was then and are still now, fresh:  What is it that you need to get the
> job done - to me, that is Doug's "Universal Unix" concept.

This is an aside, but I must admit -- with a sense of mild shame --
that the '-v' option to cat is one that I use with some regularity.
The irony is that I probably would not have done so had it NOT been
for the aforementioned paper, which made me aware of it (and how ugly
it is). That is, whenever I want to do the sort of thing that 'cat -v'
does, I remember that paper and think to myself, "oh yeah...`cat -v`
does that."

The suggested alternative of a special-purpose tool never struck me as
satisfactory since such a tool did not exist as a matter of course on
the multitude of machines that I might log into, and/or I didn't have
time or was too lazy to write it myself. Cue segue to lamentation of
the loss of systems promoting a network-aware filesystem namespace
where such things could be written once and then follow me around....

        - Dan C.

[TUHS] basic tools / Universal Unix

[Clem Cole]

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

On Mon, Oct 16, 2017 at 12:39 PM, Jon Steinhart <jon at fourwinds.com> wrote:

>
> I have a similar and maybe even more extreme position.  When I was a
> manager
> I placed restrictions on the tools and customizations for members of my
> team.
> My goal was to make sure that any team member could go over to any other
> team
> member's desk and get stuff done.


​And I think this loops back to what started some of this threat.  The idea
of a programmer with 'good taste.'
Rob (and Brian) railed on BSD in cat -v considered harmful
<http://harmful.cat-v.org/cat-v/> and ‘*Program Design in the UNIX
Environment*’ (pdf version
<http://harmful.cat-v.org/cat-v/unix_prog_design.pdf>, ps version
<http://harmful.cat-v.org/cat-v/unix_prog_design.ps>) but the points in it
was then and are still now, fresh:  What is it that you need to get the job
done - to me, that is Doug's "Universal Unix" concept.

When I answer questions on quora about learning Linux and other UNIX
derivative, I still point them at their  book:   *The Unix Programming
Environment
<http://www.amazon.com/gp/product/013937681X?ie=UTF8&tag=catv-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=013937681X>*

I would say, if the can login into the system and complete the exercises in
UPE without having to make changes, you are pretty close to Doug's
"Universal UNIX" environment.  And if you can use the tools, without having
to think about them and they pretty much are what you rely upon everyday,
you are getting close to my ideal of 'good taste.'

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171016/f5cb7a50/attachment.html>