[TUHS] Unix taste

[TUHS] Unix taste

[Noel Chiappa]

    > From: Doug McIlroy <doug at cs.dartmouth.edu>

    > Yet a quoted "wc -l" as a bare command or (I suspect) as the first
    > command in a pipeline would lead to "command not found".

I don't know about earlier versions of Unix, but FWLIW on V6 it does indeed
barf in both of these cases (just tried it).

	Noel

[TUHS] Unix taste

[A. P. Garcia]

On Aug 13, 2014 11:36 PM, "Norman Wilson" <norman at oclsc.org> wrote:
>
<snip>
> Pipelines
> (especially once they were attractive and convenient to use)
> made a bigger difference than we remember in how commands
> worked and which commands were useful.
>
> And of course Doug gets at least as much credit as Ken for
> changing our lives with all that.

What I remember reading is that once Dr. McIlroy conceived it, he wouldn't
let it go until one day Thompson announced that he was going to implement
it.

I'm curious whether he's familiar with the powershell spin on pipes and
what he thinks of it. Knowing he's something of a minimalist and a
curmudgeon, I suspect he doesn't fancy it much, but I personally think it's
a brilliant evolution of the concept. (With all due respect, of course. I
have nothing but admiration for the man.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140813/b17b93e0/attachment.html>

[TUHS] Unix taste

[Norman Wilson]

Doug McIlroy:

  The single-token rule meant that, if you wanted to supply an
  option to wc in the pipeline
          ls > wc >
  you couldn't write
          ls > wc -l >
  as one would expect, but instead had to write
          ls > "wc -l" >
  Yet a quoted "wc -l" as a bare command or (I suspect) as the
  first command in a pipeline would lead to "command not found".
  What a mess!

======

Then as now, a quoted "wc -l" would be taken by the shell
to be a single world, so

	"wc -l" file

would be a request to find a file named "wc -l" (without
the quotes but with the embedded blank) somewhere in the
search path, and execute it with argv[0] = "wc -l" and
argv[1] = "file".  But the shell's parser bound only the
word following > or < to the operator, so the command had
to be quoted (if it had arguments) to make it a single word.

So in the old syntax, if you needed to quote an argument
of a command that was part of a pipeline but not at the
head, you'd have to embed quotes within quotes; e.g.

	ls > "grep '[0-9]'" >

Decidedly a quick hack, just like the original implementation
of fork(2) (which was, approximately, swap the current process
out, but keep the in-core copy, and give one of the two a new
process ID and process-table entry).  Though unlike the original
fork, the original pipeline syntax was rough enough to be
worth fixing early on.

As a side note, when I was writing my earlier message, I was
going to construct an example using wc -l, until I checked the
manual and discovered that when pipelines were invented wc
didn't yet take options.  I also thought about an example
using grep, except grep hadn't appeared yet either.  Pipelines
(especially once they were attractive and convenient to use)
made a bigger difference than we remember in how commands
worked and which commands were useful.

And of course Doug gets at least as much credit as Ken for
changing our lives with all that.

Norman Wilson
Toronto ON

[TUHS] Unix taste

[Doug McIlroy]

Thanks, Norman, for reminding me of the actual pipe syntax in v3.
This reinforces the title of one history item on Dennis's
website: "Why Ken had to invent |".

I'd suppressed all memory of the fact that in the pipeline
        ... > cmd > ...
cmd had to be a single token. That was certainly not the intent
of my original proposal. It is understandable, though, as a
minimal hack to the existing shell syntax and its parser, which
accepted occurrences of <token and >token anywhere in a command.

The single-token rule meant that, if you wanted to supply an
option to wc in the pipeline
        ls > wc >
you couldn't write
        ls > wc -l >
as one would expect, but instead had to write
        ls > "wc -l" >
Yet a quoted "wc -l" as a bare command or (I suspect) as the
first command in a pipeline would lead to "command not found".
What a mess!

Soon after, Ken was inspired to invent the | operator, lest
he should have to describe an ugly duckling in public at an
upcoming symposium in London.

Is it possible that the ugliness of the token hack was the
precipitating factor that gave us the sublime | ?  But for
the hack, perhaps we'd still be writing
        ls > wc >

Doug

[TUHS] Unix taste

[Ed]

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

Arrow keys? Vi does arrow keys? But then I'd have to move my hand from home.
That's not vi.




--
Ed Skinner, ed at flat5.net, http://www.flat5.net/

-------- Original message --------
From: Doug McIlroy <doug@cs.dartmouth.edu> 
Date: 08/02/2014  8:38 AM  (GMT-07:00) 
To: tuhs at minnie.tuhs.org,lm at mcvoy.com 
Subject: Re: [TUHS] Unix taste 
 
> So Doug, ed?  Or what?

Yes, ed for small things. It loads instantly and works in the
current window without disturbing it. And it has been ingrained
in my fingers since Multics days.

But for heavy duty work, I use sam, in Windows as well as Linux.
Sam marries ed to screen editing much more cleanly than vi.
It has recursive global commands and infinite undo. Like qed
(whence came ed's syntax) and Larry's xvi it can work on
several files (or even several areas in one file) at once.


I would guess that a vi adept would miss having arrow keys
as well as the mouse, but probably not much else. Sam offers
one answer for my question about examples of taste reigning
in featurism during the course of Unix evolution.

Doug
_______________________________________________
TUHS mailing list
TUHS at minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs

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

[TUHS] Unix taste

[John Cowan]

Doug McIlroy scripsit:

> Yes, ed for small things. It loads instantly and works in the current
> window without disturbing it. And it has been ingrained in my fingers
> since Multics days.

I use ex exclusively, being willing to trade a little standardosity for
a little more user-friendliness.  I have no trouble switching to ed if
necessary (as when /usr is not mounted, though nowadays /usr is typically
on the root file system).  It is certainly ingrained in my fingers;
I'm using it to write this email.  I usually write scripts for ed rather
than ex, as I usually write shell scripts for a Posix shell, not for bash.

Very occasionally I switch to vi mode, mostly so I can use the % key
when editing Lisp, or to edit a highly repetitive line (try changing
"one one one one one one one one one" to "one one one one one two one
one one one" with ed/ex alone!)  The only vi commands I know are h, j,
k, l, x, i, %, and most importantly Q, which gets me back to ex mode.

My answer to "What's your IDE?" is "Console running a bunch of 'ex'
tabs and one shell tab for typing 'make'."


> But for heavy duty work, I use sam, in Windows as well as Linux.

I've tried to switch to sam several times, but so far without success.
The lack of arrow keys is annoying for close-up editing, and since I use
Windows as a terminal to hack remote Solaris or Linux systems, the lack
of -r in the Windows version of sam is very annoying.

> Sam marries ed to screen editing much more cleanly than vi.  It has
> recursive global commands and infinite undo. Like qed (whence came
> ed's syntax) and Larry's xvi it can work on several files (or even
> several areas in one file) at once.

Agreed on all points.  See esr's "A Tale of Five Editors" at
<http://www.catb.org/esr/writings/taoup/html/ch13s02.html> (be sure to
click the "Next" link for his analysis).  I contributed much of the sam
and acme/wily sections.  (I know you've read this, since you are quoted
in it, but others here may not have.)

> I would guess that a vi adept would miss having arrow keys as well
> as the mouse, but probably not much else. Sam offers one answer for
> my question about examples of taste reigning in featurism during the
> course of Unix evolution.

"Reining in", please (peeve, peeve)

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
Adam [...] did not want the apple for the apple's sake, he wanted it only
because it was forbidden. The mistake was not forbidding the serpent;
then he would have eaten the serpent. --Mark Twain

[TUHS] Unix taste

[Doug McIlroy]

> So Doug, ed?  Or what?

Yes, ed for small things. It loads instantly and works in the
current window without disturbing it. And it has been ingrained
in my fingers since Multics days.

But for heavy duty work, I use sam, in Windows as well as Linux.
Sam marries ed to screen editing much more cleanly than vi.
It has recursive global commands and infinite undo. Like qed
(whence came ed's syntax) and Larry's xvi it can work on
several files (or even several areas in one file) at once.


I would guess that a vi adept would miss having arrow keys
as well as the mouse, but probably not much else. Sam offers
one answer for my question about examples of taste reigning
in featurism during the course of Unix evolution.

Doug