9 Jun
2024
9 Jun
'24
1:34 p.m.
Eloquently put. Amen!
doug
Unix brought automation to the forefront of
possibilities. Using Unix,
anyone could do it - even that kid in Jurassic Park. Today, everything
is GUI and nothing can be automated easily or, most of the time,
not at all.
Unix is an ever shrinking oasis in a desert of
non-automation and
complexity.
It is the loss of automation possibilities that
frustrates me the most
9 Jun
9 Jun
1:59 p.m.
New subject: most direct Unix descendant
On Sun, Jun 9, 2024, 7:35 AM Douglas McIlroy <douglas.mcilroy(a)dartmouth.edu wrote:
Eloquently put. Amen!
doug
Do I have to be that guy? I hate windows. I love Unix. But the above isn't
really true. MS has actually done a good job of catching up in that
department. All major apps have Powershell libraries. I envy some features
of Powershell, but I still won't use it unless I have to.
One example is PowerCLI, which is very useful for vSphere automation.
Easier to use than their other language APIs, in my opinion. I could go on
with other examples (Active Directory, MSSQL, Exchange), but I think the
point is made...
Unix brought automation to the forefront of
possibilities. Using Unix,
anyone could do it - even that kid in Jurassic Park. Today, everything
is GUI and nothing can be automated easily or, most of the time,
not at all.
Unix is an ever shrinking oasis in a desert of
non-automation and
complexity.
It is the loss of automation possibilities that
frustrates me the most
2:31 p.m.
New subject: most direct Unix descendant
Hi A. P.,
All major apps have Powershell libraries. I envy some
features of
Powershell, but I still won't use it unless I have to.
One example is PowerCLI, which is very useful for vSphere automation.
Easier to use than their other language APIs, in my opinion.
The grandfather of your post address Powershell earlier on.
https://www.tuhs.org/mailman3/hyperkitty/list/tuhs@tuhs.org/message/QZVFRCY…
The concept of producing a stream of text as the
output of a program
that does simple jobs well has been replaced by "power-shell" thinking
of passing binary objects rather than text between program
- a decidedly non-portable idea.
Passing "objects" requires attaching to a dynamically linked library
(that will change or even disappear with the next release of the OS or
the object library). With Research Unix, I could pipe the output of
a Unix program running on an Intel 486 to another program running on
a Motorola 68000 or a Zilog Z80000 or an IBM AIX machine.
--
Cheers, Ralph.
4:06 p.m.
New subject: most direct Unix descendant
On Sun, Jun 9, 2024, 8:40 AM Ralph Corderoy <ralph(a)inputplus.co.uk> wrote:
Hi A. P.,
Thank you, I hadn't seen that. He's right, of course. It's kludgy, but you
can always use text, or some structured form of it like json or xml, to
communicate between different machines. Does windows have something like
netcat/socat? I honestly don't know.
All major apps have Powershell libraries. I envy
some features of
Powershell, but I still won't use it unless I have to.
One example is PowerCLI, which is very useful for vSphere automation.
Easier to use than their other language APIs, in my opinion.
The grandfather of your post address Powershell earlier on.
https://www.tuhs.org/mailman3/hyperkitty/list/tuhs@tuhs.org/message/QZVFRCY…
The concept of producing a stream of text as the
output of a program
that does simple jobs well has been replaced by "power-shell" thinking
of passing binary objects rather than text between program
- a decidedly non-portable idea.
Passing "objects" requires attaching to a dynamically linked library
(that will change or even disappear with the next release of the OS or
the object library). With Research Unix, I could pipe the output of
a Unix program running on an Intel 486 to another program running on
a Motorola 68000 or a Zilog Z80000 or an IBM AIX machine.
--
Cheers, Ralph.
10 Jun
10 Jun
7:13 a.m.
New subject: most direct Unix descendant
Hi A.P.,
I agree powershell supports automation. However, it so complex and
non-portable
that even learning about it and how to use it takes considerably longer than
learning about Unix automation. It puts a significant burden on developers
to
document their DLL's and make the interfaces permanent. Complexity produces
more
expensive and less reliable software.
BTW, what about the non-major apps? From your view, they are simply excluded
from automation.
In PS, type "help cmdlet" to see
the complexity of each and every command. PS does allow automation, but
it is very expensive because most people will be daunted when trying to
learn how
to solve problems with it, people who know how to write stuff in PS are
more expensive
employees, and development time for asking a simple question like
"Show me the last 5 files read in a directory tree"
can require days or more of research and experimentation.
A help page on almost any cmdlet produces a full page-width
pages of options, many of which lead to further questions about
usage.
Yes, PS automates Windows -- but at what cost?
Ed
PS: I should write my book of "Why Windows is not my favorite
operating system" (paraphrasing a famous BTL TM).
PS2: Speaking of complexity and documentation, here is the start
of the printout on an up-to-date MacOS of the command
man ls | less
*NAME ls – list directory contents SYNOPSIS ls
[-@ABCFGHILOPRSTUWabcdefghiklmnopqrstuvwxy1%,] [--color=when] [-D
format] [file ...]*
and the same question about "ls" on Windows 11 powershell:
help ls | less # typed in PS
[image: image.png]
How did we let this happen?
On Sun, Jun 9, 2024 at 6:59 AM A. P. Garcia <a.phillip.garcia(a)gmail.com>
wrote:
On Sun, Jun 9, 2024, 7:35 AM Douglas McIlroy <
douglas.mcilroy(a)dartmouth.edu> wrote:
--
Advice is judged by results, not by intentions.
Cicero
Eloquently put. Amen!
doug
Do I have to be that guy? I hate windows. I love Unix. But the above isn't
really true. MS has actually done a good job of catching up in that
department. All major apps have Powershell libraries. I envy some features
of Powershell, but I still won't use it unless I have to.
One example is PowerCLI, which is very useful for vSphere automation.
Easier to use than their other language APIs, in my opinion. I could go on
with other examples (Active Directory, MSSQL, Exchange), but I think the
point is made...
> Unix brought automation to the forefront of
possibilities. Using Unix,
anyone could do it - even that kid in Jurassic Park. Today, everything
is GUI and nothing can be automated easily or, most of the time,
not at all.
Unix is an ever shrinking oasis in a desert of
non-automation and
complexity.
It is the loss of automation possibilities that
frustrates me the most
7:25 a.m.
New subject: most direct Unix descendant
At 2024-06-10T00:13:08-0500, Ed Bradford wrote:
PS2: Speaking of complexity and documentation, here is
the start
of the printout on an up-to-date MacOS of the command
man ls | less
[...]
How did we let this happen?
When "everything is a file", a lot gets packed into one's file
abstraction.
Regards,
Branden
10:39 a.m.
New subject: most direct Unix descendant
On Mon, 10 Jun 2024, Ed Bradford wrote:
[...] people who know how to write stuff in PS are
more expensive
employees, and development time for asking a simple question like
"Show me the last 5 files read in a directory tree"
Likely a one-liner in Unix :-)
-- Dave
11:36 a.m.
New subject: most direct Unix descendant
The architectural alternative to powershell-style extension has been around
in various guises for a while. In particular things like TCL and Lua are
engineered to be add-on extension languages. Integrating them just
involves adding a few callouts (dispatch a “program”, scan directories in a
designated “path” for programs, render internal structures into text).
This style of design has been around for a long time - all Unix shells,
EMacs, many video games.
It enables an elegant approach to performance management - build it first
as a script and only reimplement it as a binary if needed.
Doing this enables automation, but it does require the designers and
product managers to want automation.
Marc
=====
nygeek.net
mindthegapdialogs.com/home <https://www.mindthegapdialogs.com/home>
On Mon, Jun 10, 2024 at 4:39 AM Dave Horsfall <dave(a)horsfall.org> wrote:
On Mon, 10 Jun 2024, Ed Bradford wrote:
[...] people who know how to write stuff in PS
are more expensive
employees, and development time for asking a simple question like
"Show me the last 5 files read in a directory tree"
Likely a one-liner in Unix :-)
-- Dave 
9:40 p.m.
New subject: most direct Unix descendant
Marc Donner wrote in
<CALQ0xCCNYP26Crv6m6Xp7efBL-wzfTB=fgZa9cKkVFvNacv-tw(a)mail.gmail.com>:
|The architectural alternative to powershell-style extension has been around
|in various guises for a while. In particular things like TCL and Lua are
|engineered to be add-on extension languages. Integrating them just
|involves adding a few callouts (dispatch a “program”, scan directories in a
|designated “path” for programs, render internal structures into text).
|
|This style of design has been around for a long time - all Unix shells,
|EMacs, many video games.
|
|It enables an elegant approach to performance management - build it first
|as a script and only reimplement it as a binary if needed.
|
|Doing this enables automation, but it does require the designers and
|product managers to want automation.
Let me be the one who feed the silent head shakers with the
Rob Pike quote "[just] make it strings".
Of course lua hooks are faster, and i am looking forward myself,
but other than that textual input/output communication with
a program is language-neutral and somehow humanic.
So now the time has come to point to an influential -- for me --
manual from 2001, that goes into assembler programming for x86:
https://docs.freebsd.org/en/books/developers-handbook/x86/
And there you read things like
A.12. One-Pointed Mind
As a student of Zen, I like the idea of a one-pointed mind: Do
one thing at a time, and do it well.
This, indeed, is very much how UNIX® works as well. While
a typical Windows® application is attempting to do everything
imaginable (and is, therefore, riddled with bugs), a typical
UNIX® program does only one thing, and it does it well.
The typical UNIX® user then essentially assembles his own
applications by writing a shell script which combines the
various existing programs by piping the output of one program to
the input of another.
When writing your own UNIX® software, it is generally a good
idea to see what parts of the problem you need to solve can be
handled by existing programs, and only write your own programs
for that part of the problem that you do not have an existing
solution for.
And going over
A.13.2. Excursion to Pinhole Photography
we come to the
A.13.3.1. Processing Program Input
which was a stunning read for me (the 15+ years before i came via
Commodore 64 and its Basic, over Windows 3.1 and Windows 95 and,
alongside, DOS, later 4DOS (then perl etc.)), because when doing
really, really important things like calculating the cubic
capacity of ones penis' in cubic millimeters (to end up with large
numbers, say), i would never have thought by myself that the
program accept and parse running text! (There you see that
something "big" can actually be pretty "small" indeed.)
Personally, I like to keep it simple. Something either is
a number, so I process it. Or it is not a number, so I discard
it. I do not like the computer complaining about me typing in an
extra character when it is obvious that it is an extra
character. Duh.
Plus, it allows me to break up the monotony of computing and
type in a query instead of just a number:
What is the best pinhole diameter for the focal length of 150?
There is no reason for the computer to spit out a number of complaints:
Syntax error: What
Syntax error: is
Syntax error: the
Syntax error: best
Et cetera, et cetera, et cetera.
And this (assembler!) then goes to
% pinhole
Computer,
What size pinhole do I need for the focal length of 150?
150 490 306 362 2930 12
Hmmm... How about 160?
160 506 316 362 3125 12
Let's make it 155, please.
155 498 311 362 3027 12
Ah, let's try 157...
157 501 313 362 3066 12
156?
156 500 312 362 3047 12
That's it! Perfect! Thank you very much!
^D
which is not even handled by GNU getopt with its
argument-resorting behaviour!
But it is likely that you all do not need that no more anyway,
since you likely just speak out (silently at "Hal" level) "Hey
computer bla bla", and the AI does the rest itself.
--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)
10:09 p.m.
New subject: most direct Unix descendant
Totally correct - in the words of the immortal Beatles - "Strings is all
you need."
=====
nygeek.net
mindthegapdialogs.com/home <https://www.mindthegapdialogs.com/home>
On Mon, Jun 10, 2024 at 3:40 PM Steffen Nurpmeso <steffen(a)sdaoden.eu> wrote:
Marc Donner wrote in
<CALQ0xCCNYP26Crv6m6Xp7efBL-wzfTB=fgZa9cKkVFvNacv-tw(a)mail.gmail.com>:
|The architectural alternative to powershell-style extension has been
around
|in various guises for a while. In particular things like TCL and Lua are
|engineered to be add-on extension languages. Integrating them just
|involves adding a few callouts (dispatch a “program”, scan directories
in a
|designated “path” for programs, render internal structures into text).
|
|This style of design has been around for a long time - all Unix shells,
|EMacs, many video games.
|
|It enables an elegant approach to performance management - build it first
|as a script and only reimplement it as a binary if needed.
|
|Doing this enables automation, but it does require the designers and
|product managers to want automation.
Let me be the one who feed the silent head shakers with the
Rob Pike quote "[just] make it strings".
Of course lua hooks are faster, and i am looking forward myself,
but other than that textual input/output communication with
a program is language-neutral and somehow humanic.
So now the time has come to point to an influential -- for me --
manual from 2001, that goes into assembler programming for x86:
https://docs.freebsd.org/en/books/developers-handbook/x86/
And there you read things like
A.12. One-Pointed Mind
As a student of Zen, I like the idea of a one-pointed mind: Do
one thing at a time, and do it well.
This, indeed, is very much how UNIX® works as well. While
a typical Windows® application is attempting to do everything
imaginable (and is, therefore, riddled with bugs), a typical
UNIX® program does only one thing, and it does it well.
The typical UNIX® user then essentially assembles his own
applications by writing a shell script which combines the
various existing programs by piping the output of one program to
the input of another.
When writing your own UNIX® software, it is generally a good
idea to see what parts of the problem you need to solve can be
handled by existing programs, and only write your own programs
for that part of the problem that you do not have an existing
solution for.
And going over
A.13.2. Excursion to Pinhole Photography
we come to the
A.13.3.1. Processing Program Input
which was a stunning read for me (the 15+ years before i came via
Commodore 64 and its Basic, over Windows 3.1 and Windows 95 and,
alongside, DOS, later 4DOS (then perl etc.)), because when doing
really, really important things like calculating the cubic
capacity of ones penis' in cubic millimeters (to end up with large
numbers, say), i would never have thought by myself that the
program accept and parse running text! (There you see that
something "big" can actually be pretty "small" indeed.)
Personally, I like to keep it simple. Something either is
a number, so I process it. Or it is not a number, so I discard
it. I do not like the computer complaining about me typing in an
extra character when it is obvious that it is an extra
character. Duh.
Plus, it allows me to break up the monotony of computing and
type in a query instead of just a number:
What is the best pinhole diameter for the focal length of 150?
There is no reason for the computer to spit out a number of complaints:
Syntax error: What
Syntax error: is
Syntax error: the
Syntax error: best
Et cetera, et cetera, et cetera.
And this (assembler!) then goes to
% pinhole
Computer,
What size pinhole do I need for the focal length of 150?
150 490 306 362 2930 12
Hmmm... How about 160?
160 506 316 362 3125 12
Let's make it 155, please.
155 498 311 362 3027 12
Ah, let's try 157...
157 501 313 362 3066 12
156?
156 500 312 362 3047 12
That's it! Perfect! Thank you very much!
^D
which is not even handled by GNU getopt with its
argument-resorting behaviour!
But it is likely that you all do not need that no more anyway,
since you likely just speak out (silently at "Hal" level) "Hey
computer bla bla", and the AI does the rest itself.
--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)
10:19 p.m.
New subject: most direct Unix descendant
Marc Donner wrote in
<CALQ0xCD0YPurnXnWnK6Q-E0ndXwztzoYHKK9Pr+Sef8=XGtb2Q(a)mail.gmail.com>:
|Totally correct - in the words of the immortal Beatles - "Strings is all
|you need."
Sounds a bit like a somewhat pissed younger John Lennon?
Iggy's "put some strings, you know" on some of those photograph
seamy American carpets.
(Of course -- i have no idea of what i am talking about.)
--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)
11 Jun
11 Jun
5:15 a.m.
New subject: Likely a one-liner in Unix
OK, I'll bite (NB: using GNU find):
find "$directory_tree" -type f -printf "%A+ %p\n" | sort -r | cut
-d' '
-f2 | head -5
Cheers,
/Frew
On 2024-06-10 01:39, Dave Horsfall wrote:
On Mon, 10 Jun 2024, Ed Bradford wrote:
[...] people who know how to write stuff in PS
are more expensive
employees, and development time for asking a simple question like
"Show me the last 5 files read in a directory tree"
Likely a one-liner in Unix :-)
-- Dave
10:05 a.m.
New subject: Likely a one-liner in Unix
Hi James,
> > "Show me the last 5 files read in a
directory tree"
Given sort(1) gained -u for efficiency, I've often wondered why, in
those constrained times, it didn't have a ‘-m n’ to output only the
n ‘minimums’, e.g. ‘sed ${n}q’. With ‘-m 5’, this would let sort track
the current fifth entry and discard input which was bigger, so avoiding
both storing many unwanted lines and finding the current line's location
within them.
OK, I'll bite (NB: using GNU find):
I think the POSIX way of getting the atime would be ‘LC_CTIME=C ls -lu’
and then parsing the two possible date formats. So non-POSIX find is
simpler. Also, GNU find shows me the sub-second part but ls doesn't.
Neither does GNU ‘stat -c '%X %n'’.
find "$directory_tree" -type f -printf
"%A+ %p\n" | sort -r | cut -d' ' -f2 | head -5
- I'd switch the atime format to seconds since epoch for easier
formatting given it's discarded.
- When atimes tie, sort's -r will give file Z before A so I'd add some
-k's so A comes first.
- I'd move the head to before the cut so cut processes fewer lines...
- But on so few lines, I'd just use sed to do both in one.
find "$@" -type f -printf '%A@ %p\n' |
sort -k1,1nr -k2 |
sed 's/^[^ ]* //; 5q'
Remaining issues...
If tied entries bridge the top-five border then this isn't shown.
Is the real requirement to show files with the five most recent distinct
atimes?
awk '{t += !s[$0]; s[$0] = 1; print} t == 5 {exit}'
Though this might give many lines. Instead, an ellipsis could show
a tie bridged the cut-off.
awk 't {if ($0 == l) print "..."; exit} NR == 5 {l = $0; t = 1}
1'
Paths can contain linefeeds and some versions allow handling NULs to be
tediously employed.
find "$@" -type f -printf '%A@ %p\0' |
sort -z -k1,1nr -k2 |
sed -z 's/[^ ]* //; 5q' |
tr \\0 \\n
David Wheeler has a nice article he maintains on unusual characters in
filenames: how to cope, and what other systems do, e.g. Plan 9.
Fixing Unix/Linux/POSIX filenames: control characters (such as
newline), leading dashes, and other problems
David A. Wheeler, 2023-08-22 (originally 2009-03-24)
https://dwheeler.com/essays/fixing-unix-linux-filenames.html
As he writes, Linux already returns EINVAL for some paths on some
filesystem types. A mount option which had a syscall return an error on
meeting an insensible path would be useful. It avoids any attempt at
escapement and its greater risk of implementation errors. I could
always re-mount some old volume without the option to list the directory
and fix up its entries. The second-best day to plant a tree is today.
--
Cheers, Ralph.
11:01 p.m.
New subject: Likely a one-liner in Unix
Ralph Corderoy wrote in
<20240611080506.73D7B21309(a)orac.inputplus.co.uk>:
..
|>>> "Show me the last 5 files read in a directory tree"
...
|Neither does GNU ‘stat -c '%X %n'’.
Unfortunately "stat" is not portable.
...
|David Wheeler has a nice article he maintains on unusual characters in
|filenames: how to cope, and what other systems do, e.g. Plan 9.
|
| Fixing Unix/Linux/POSIX filenames: control characters (such as
| newline), leading dashes, and other problems
| David A. Wheeler, 2023-08-22 (originally 2009-03-24)
| https://dwheeler.com/essays/fixing-unix-linux-filenames.html
|
|As he writes, Linux already returns EINVAL for some paths on some
|filesystem types. A mount option which had a syscall return an error on
|meeting an insensible path would be useful. It avoids any attempt at
|escapement and its greater risk of implementation errors. I could
|always re-mount some old volume without the option to list the directory
|and fix up its entries. The second-best day to plant a tree is today.
dash is currently implementing $'' quotes (that will be part of
the next POSIX i think). I want to mention again, eh, please let
me just paste something of mine from ossec from may, as i really
think in $'' could lie sanity also for such things:
While here please let me back the not yet gracefully supported
shell escape mechanism $''.
The current approach seems to be to be as atomic as possible:
# touch $(printf 'a\rb\tc\a')
# ll
->
-rw-r----- 1 steffen steffen 0 May 3 00:46 'c'$'\a'
-rw-r----- 1 steffen steffen 0 May 3 00:46
'a'$'\r''b'
(GNU coreutils). Isn't that just terrible? In (the development
version of) my mailer tab-completion leads to
#..mbox? /tmp/<TAB>
$'a\rb'
$'c\a'
which i find at least a little bit better. (Do not even think
about looking in its implementation though, look ICU or what.)
And even though currently unsupported, it should be said that with
"grapheme clusters" and in general things like ligatures and other
such language-specific constructs which need to look at
surroundings -- in general interfaces like towupper() etc are not
useful in global context, entire sentences have to be looked at as
a whole due to this! --, shell quotes should be extended to the
largest possible range possible. Ie, all the iconv(3)s that are
currently used because of a lack of other interfaces should be
enabled to see the longest possible (sub)string, not the most
atomar, as seen above.
Anyhow, with proper $'' quoting that also offers \$VAR/\${VAR} for
example (which acts like "$VAR" in double quotes; and \c@==NUL,
xx) there would be a way to a have a holistic quoting mechanism.
Some more complaining of an idiot who does not understand why ISO
C and more standardized holes in the \U and \u (Unicode code
point, hexadecimal) ranges.
--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)
146
days inactive
148
days old
13 comments
9 participants
participants (9)
-
A. P. Garcia -
Dave Horsfall -
Douglas McIlroy -
Ed Bradford -
G. Branden Robinson -
James Frew -
Marc Donner -
Ralph Corderoy -
Steffen Nurpmeso