[TUHS] basic tools / Universal Unix

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

basic tools / Universal Unix

[Tom Ivar Helbekkmo]

Clem Cole <clemc at ccc.com> writes:

> 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 never got around to reading that book until I'd been a sysadmin for
about twenty years, and it was still a revelation.  I thought I'd just
skim through it to sort of check it off the list, but I ended up
learning a lot of great stuff.

That one, and Kernighan and Pike: "The Practice of Programming", are two
books I keep recommending to people.

-tih
-- 
Most people who graduate with CS degrees don't understand the significance
of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay

[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

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

basic tools / Universal Unix

[Toby Thain]

On 2017-10-16 2:16 PM, Tom Ivar Helbekkmo wrote:
> Clem Cole <clemc at ccc.com> writes:
> 
>> 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 never got around to reading that book until I'd been a sysadmin for
> about twenty years, and it was still a revelation.  I thought I'd just
> skim through it to sort of check it off the list, but I ended up
> learning a lot of great stuff.
> 
> That one, and Kernighan and Pike: "The Practice of Programming", are two
> books I keep recommending to people.

"The Elements of Programming Style" remains as relevant as ever.

--Toby


> 
> -tih
> 

[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

[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

[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

[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

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