On 11/15/2023 3:18 AM, Ahem A Rivet's Shot wrote:
> On Wed, 15 Nov 2023 07:58:47 +0000
> Pancho <Pancho.Jones@proton.me> wrote:
>> On 14/11/2023 23:58, Martin Gregorie wrote:
>>> I did like the customisable editor too and, IIRD, the ability to attach
>>> customisations to file types. If there was an open source version of
>>> that editor I might even be using it still.
>>>
>>
>> If you mean EVE based on Vax/TPU it was ported to Unix, circa ~1995,
>> SunOS, or possibly Solaris. So it is possible there is a version
>> floating about.

There was also nuTPU for PC. Was as in "35 years ago". I don't think
they exist anymore.

> Apparently there's an emulation of EVE available for Emacs.

EVE <> TPU

Mapping EVE keyboard definition in Emacs should be piece of cake.

Getting TPU code interpreted in Emacs is a different thing. TPU
is Pascal like not Lisp like. :-)

Arne

On 2023-11-14 20:50, Jim Jackson wrote:
> On 2023-11-14, Johnny Billquist <bqt@softjar.se> wrote:
>>
>> With find it don't matter. Even the original is crazy. The one tool
>> where the Unix paradigm got completely lost...
>
> I'm baffled by this.
>
> find finds stuff in the filesystem that match some conditions.
>
> What else does it do?

Well, the question is - what does it do beyond walking the file system.
Because it don't stop there.
But first of all, it can walk the file system in different ways, and it
can do selections while walking the file systems in myriads of ways.
But then when it does match things, it can do all kind of stuff.
Do you even understand how to use "prune" for example? If you do, try it
and see if it actually gives the result you expect. (Yes, it is possible
to use in the way one thinks, but it's not trivial to understand how it
can be used.)

But in the end, find can then run any arbitrary command, might not even
be related to the files matched, but you can also make it run commands
with the matching file name put into the command line.

Johnny

On 2023-11-15, Johnny Billquist <bqt@softjar.se> wrote:
> On 2023-11-14 20:50, Jim Jackson wrote:
>> On 2023-11-14, Johnny Billquist <bqt@softjar.se> wrote:
>>>
>>> With find it don't matter. Even the original is crazy. The one tool
>>> where the Unix paradigm got completely lost...
>>
>> I'm baffled by this.
>>
>> find finds stuff in the filesystem that match some conditions.
>>
>> What else does it do?
>
> Well, the question is - what does it do beyond walking the file system.
> Because it don't stop there.
> But first of all, it can walk the file system in different ways, and it
> can do selections while walking the file systems in myriads of ways.
> But then when it does match things, it can do all kind of stuff.
> Do you even understand how to use "prune" for example? If you do, try it
> and see if it actually gives the result you expect. (Yes, it is possible
> to use in the way one thinks, but it's not trivial to understand how it
> can be used.)
>
> But in the end, find can then run any arbitrary command, might not even
> be related to the files matched, but you can also make it run commands
> with the matching file name put into the command line.

Yes it can ANOTHER command, big deal - vi is an editor and you can run
a command from it, so what.

As I said above find finds stuff in the filesystem that match some conditions.
The fact that the filesystem is complex, so the condition matching is
complex is by-the-by.

Find does one thing and does it well.

On Wed, 15 Nov 2023 08:06:00 -0500
Arne Vajhøj <arne@vajhoej.dk> wrote:

> On 11/15/2023 2:44 AM, Ahem A Rivet's Shot wrote:

> > I don't know about McDonald's but these days a lot of really big
> > systems run as a large (and variable) number of micro-services in
> > containers under Kubernetes. Scalability is the watchword today.
> > Sometimes they run on Z/OS machines (usually running Linux) otherwise
> > they run on a mix of blade servers (CPU and RAM tightly packed) and SAN
> > storage (lots of NVMe SSDs) connected with 40Gb or 100Gb ethernet.
> > Infrastructure as a service they call it.
>
> Most run such workloads in AWS/Azure/GCP/OCI.

Of course, these environments are built for that purpose and allow
the systems developers to assume the Kubernetes infrastructure without
having to maintain it. But it is possible to run such workloads in a
private data centre - "TrueNAS Scale" is one fairly easy way.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
Host: Beautiful Theory meet Inconvenient Fact
Obit: Beautiful Theory died today of factual inconsistency

On 2023-11-15 15:58, Jim Jackson wrote:
> On 2023-11-15, Johnny Billquist <bqt@softjar.se> wrote:
>> On 2023-11-14 20:50, Jim Jackson wrote:
>>> On 2023-11-14, Johnny Billquist <bqt@softjar.se> wrote:
>>>>
>>>> With find it don't matter. Even the original is crazy. The one tool
>>>> where the Unix paradigm got completely lost...
>>>
>>> I'm baffled by this.
>>>
>>> find finds stuff in the filesystem that match some conditions.
>>>
>>> What else does it do?
>>
>> Well, the question is - what does it do beyond walking the file system.
>> Because it don't stop there.
>> But first of all, it can walk the file system in different ways, and it
>> can do selections while walking the file systems in myriads of ways.
>> But then when it does match things, it can do all kind of stuff.
>> Do you even understand how to use "prune" for example? If you do, try it
>> and see if it actually gives the result you expect. (Yes, it is possible
>> to use in the way one thinks, but it's not trivial to understand how it
>> can be used.)
>>
>> But in the end, find can then run any arbitrary command, might not even
>> be related to the files matched, but you can also make it run commands
>> with the matching file name put into the command line.
>
> Yes it can ANOTHER command, big deal - vi is an editor and you can run
> a command from it, so what.
>
> As I said above find finds stuff in the filesystem that match some conditions.
> The fact that the filesystem is complex, so the condition matching is
> complex is by-the-by.
>
> Find does one thing and does it well.

Well. I don't fully agree with that, but I'm fine with just disagreeing
without getting into any further discussions. I can certainly dig up
other tools under Unix which left the "unix paradigm" behind a long time
ago, if you want.

COPY under VMS only does one thing as well, which is just copying files.
So I still do not think VMS is really much different from Unix. The OP
seems to have been using VMS with some additional layer which conflated
the view, and don't really expose how one normally interacts with VMS.
And that twisted experiece seems to have been the reason for the comment
to start with. So I think we can lay this whole thread down.

Johnny

On Wed, 15 Nov 2023 16:59:23 +0100
Johnny Billquist <bqt@softjar.se> wrote:

> Well. I don't fully agree with that, but I'm fine with just disagreeing
> without getting into any further discussions. I can certainly dig up
> other tools under Unix which left the "unix paradigm" behind a long time
> ago, if you want.

Emacs springs to mind.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
Host: Beautiful Theory meet Inconvenient Fact
Obit: Beautiful Theory died today of factual inconsistency

Ahem A Rivet's Shot <steveo@eircom.net> writes:
> Johnny Billquist <bqt@softjar.se> wrote:
>> Well. I don't fully agree with that, but I'm fine with just disagreeing
>> without getting into any further discussions. I can certainly dig up
>> other tools under Unix which left the "unix paradigm" behind a long time
>> ago, if you want.
>
> Emacs springs to mind.

Originated outside Unix, I think.

dd seems like a good example. Present at least as far back as V5 Unix
but its interface is belligerently different from any other Unix tool,
and it’s at best an uneasy fit with the “do one thing well” approach of
many of its siblings.

--
https://www.greenend.org.uk/rjk/

On Wednesday, November 15, 2023 at 9:04:28 AM UTC-8, Richard Kettlewell wrote:
> Ahem A Rivet's Shot <ste...@eircom.net> writes:
> > Johnny Billquist <b...@softjar.se> wrote:
> >> Well. I don't fully agree with that, but I'm fine with just disagreeing
> >> without getting into any further discussions. I can certainly dig up
> >> other tools under Unix which left the "unix paradigm" behind a long time
> >> ago, if you want.
> >
> > Emacs springs to mind.
> Originated outside Unix, I think.
>
> dd seems like a good example. Present at least as far back as V5 Unix
> but its interface is belligerently different from any other Unix tool,
> and it’s at best an uneasy fit with the “do one thing well” approach of
> many of its siblings.

The reason "dd" is so different from other UNIX tools is that it's a parody of the "DD" statement in IBM's JCL.

Ahem A Rivet's Shot <steveo@eircom.net> writes:

> On Wed, 15 Nov 2023 16:59:23 +0100
> Johnny Billquist <bqt@softjar.se> wrote:

>> Well. I don't fully agree with that, but I'm fine with just disagreeing
>> without getting into any further discussions. I can certainly dig up
>> other tools under Unix which left the "unix paradigm" behind a long time
>> ago, if you want.

> Emacs springs to mind.

Emacs is not a native Unix program.

It originated as a library of functions written in an enhanced TECO for the
PDP-10 that ran under ITS (MIT), TENEX (BBN), and TOPS-20 (TENEX with the
serial numbers filed off by DEC).

It was ported to an MIT dialect of LISP running under Multics, then versions
for the MIT inspired Lisp machines came along.

The C ports (including GNU) hark back to these Lisp versions.

So there's no reason to expect Emacs to be a Unix style program.

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

Richard Kettlewell <invalid@invalid.invalid> writes:

> Ahem A Rivet's Shot <steveo@eircom.net> writes:
>> Johnny Billquist <bqt@softjar.se> wrote:
>>> Well. I don't fully agree with that, but I'm fine with just disagreeing
>>> without getting into any further discussions. I can certainly dig up
>>> other tools under Unix which left the "unix paradigm" behind a long time
>>> ago, if you want.

>> Emacs springs to mind.
>
> Originated outside Unix, I think.

Indeed.

> dd seems like a good example. Present at least as far back as V5 Unix
> but its interface is belligerently different from any other Unix tool,
> and it's at best an uneasy fit with the "do one thing well" approach of
> many of its siblings.

dd was intentionally designed to mimic the behavior of OS/360 Job Control
Language's Data Definition (DD) cards. It does that thing, and that thing
only, very well.

So dd has the Unix Nature (R).

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

On 2023-11-15 17:06, Ahem A Rivet's Shot wrote:
> On Wed, 15 Nov 2023 16:59:23 +0100
> Johnny Billquist <bqt@softjar.se> wrote:
>
>> Well. I don't fully agree with that, but I'm fine with just disagreeing
>> without getting into any further discussions. I can certainly dig up
>> other tools under Unix which left the "unix paradigm" behind a long time
>> ago, if you want.
>
> Emacs springs to mind.

Well - Emacs don't really come from the Unix world to start with...

But systemd always comes to my mind...

Johnny

On 2023-11-15 18:04, Richard Kettlewell wrote:
> Ahem A Rivet's Shot <steveo@eircom.net> writes:
>> Johnny Billquist <bqt@softjar.se> wrote:
>>> Well. I don't fully agree with that, but I'm fine with just disagreeing
>>> without getting into any further discussions. I can certainly dig up
>>> other tools under Unix which left the "unix paradigm" behind a long time
>>> ago, if you want.
>>
>> Emacs springs to mind.
>
> Originated outside Unix, I think.

Yes. PDP-10s. If it was ITS or TOPS-20 at the start, I dare not say.
Written in TECO.

> dd seems like a good example. Present at least as far back as V5 Unix
> but its interface is belligerently different from any other Unix tool,
> and it’s at best an uneasy fit with the “do one thing well” approach of
> many of its siblings.

I have some recollection that dd's interface comes from something like
IBMs OS/360. But I could be very wrong on that one.

Johnny

On 2023-11-15 20:31, Jake Hamby (Solid State Jake) wrote:
> On Wednesday, November 15, 2023 at 9:04:28 AM UTC-8, Richard Kettlewell wrote:
>> Ahem A Rivet's Shot <ste...@eircom.net> writes:
>>> Johnny Billquist <b...@softjar.se> wrote:
>>>> Well. I don't fully agree with that, but I'm fine with just disagreeing
>>>> without getting into any further discussions. I can certainly dig up
>>>> other tools under Unix which left the "unix paradigm" behind a long time
>>>> ago, if you want.
>>>
>>> Emacs springs to mind.
>> Originated outside Unix, I think.
>>
>> dd seems like a good example. Present at least as far back as V5 Unix
>> but its interface is belligerently different from any other Unix tool,
>> and it’s at best an uneasy fit with the “do one thing well” approach of
>> many of its siblings.
>
> The reason "dd" is so different from other UNIX tools is that it's a parody of the "DD" statement in IBM's JCL.

Not sure it's meant as a parody. Don't even know what one would want to
paridy such a thing. But I do remember seeing/hearing about it coming
from some IBM thing.

Johnny

On 11/15/2023 11:06 AM, Ahem A Rivet's Shot wrote:
> On Wed, 15 Nov 2023 16:59:23 +0100
> Johnny Billquist <bqt@softjar.se> wrote:
>
>> Well. I don't fully agree with that, but I'm fine with just disagreeing
>> without getting into any further discussions. I can certainly dig up
>> other tools under Unix which left the "unix paradigm" behind a long time
>> ago, if you want.
>
> Emacs springs to mind.
>

Emacs has nothing to do with Unix other than the fact that
someone ported it late in the game.

bill

On 14/11/2023 09:30, Johnny Billquist wrote:
> Source management is usually handled by one single program, even on most
> systems today. Be that cvs, svn, git or whatever.

git is actually a collection of programs, when you run

git command args

it actually runs

git-command args

You can even write your own git utilities, call them git-something and
put them on PATH, and they will run when you do

git something

---druck

On 15 Nov 2023 at 20:49:52 GMT, "Rich Alderson"
<news@alderson.users.panix.com> wrote:

> So there's no reason to expect Emacs to be a Unix style program.

I don't expect Emacs any more than I expect the Spanish Inquisition.

--
Tim

On 15 Nov 2023 at 20:59:37 GMT, "Johnny Billquist" <bqt@softjar.se> wrote:

> On 2023-11-15 18:04, Richard Kettlewell wrote:
>> Ahem A Rivet's Shot <steveo@eircom.net> writes:
>>> Johnny Billquist <bqt@softjar.se> wrote:
>>>> Well. I don't fully agree with that, but I'm fine with just disagreeing
>>>> without getting into any further discussions. I can certainly dig up
>>>> other tools under Unix which left the "unix paradigm" behind a long time
>>>> ago, if you want.
>>>
>>> Emacs springs to mind.
>>
>> Originated outside Unix, I think.
>
> Yes. PDP-10s. If it was ITS or TOPS-20 at the start, I dare not say.
> Written in TECO.

In commands that look like line-noise.

>> dd seems like a good example. Present at least as far back as V5 Unix
>> but its interface is belligerently different from any other Unix tool,
>> and it’s at best an uneasy fit with the “do one thing well” approach of
>> many of its siblings.
>
> I have some recollection that dd's interface comes from something like
> IBMs OS/360. But I could be very wrong on that one.

Fortunately I was able to avoid that.

--
Tim

On Wed, 15 Nov 2023 21:57:45 +0100
Johnny Billquist <bqt@softjar.se> wrote:

> On 2023-11-15 17:06, Ahem A Rivet's Shot wrote:

> > Emacs springs to mind.
>
> Well - Emacs don't really come from the Unix world to start with...

True - Teco editing macros originally.

> But systemd always comes to my mind...

I try not to let it <shudder> - anyway that's a Linux thing not seen
on any other unix (it's one reason I tend to avoid Linux). Apparently it's
not even remotely portable.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
Host: Beautiful Theory meet Inconvenient Fact
Obit: Beautiful Theory died today of factual inconsistency

On 2023-11-15 22:42, TimS wrote:
> On 15 Nov 2023 at 20:49:52 GMT, "Rich Alderson"
> <news@alderson.users.panix.com> wrote:
>
>> So there's no reason to expect Emacs to be a Unix style program.
>
> I don't expect Emacs any more than I expect the Spanish Inquisition.

Nobody...

Johnny

On 2023-11-15 22:44, TimS wrote:
> On 15 Nov 2023 at 20:59:37 GMT, "Johnny Billquist" <bqt@softjar.se> wrote:
>
>> On 2023-11-15 18:04, Richard Kettlewell wrote:
>>> Ahem A Rivet's Shot <steveo@eircom.net> writes:
>>>> Johnny Billquist <bqt@softjar.se> wrote:
>>>>> Well. I don't fully agree with that, but I'm fine with just disagreeing
>>>>> without getting into any further discussions. I can certainly dig up
>>>>> other tools under Unix which left the "unix paradigm" behind a long time
>>>>> ago, if you want.
>>>>
>>>> Emacs springs to mind.
>>>
>>> Originated outside Unix, I think.
>>
>> Yes. PDP-10s. If it was ITS or TOPS-20 at the start, I dare not say.
>> Written in TECO.
>
> In commands that look like line-noise.

It has been described as a write-only language. Not undeservedly.

That said - I do like to use TECO once in a while. It's still a pretty
good tool.

Johnny

On 2023-11-15 22:34, Ahem A Rivet's Shot wrote:
> On Wed, 15 Nov 2023 21:57:45 +0100
> Johnny Billquist <bqt@softjar.se> wrote:
>
>> But systemd always comes to my mind...
>
> I try not to let it <shudder> - anyway that's a Linux thing not seen
> on any other unix (it's one reason I tend to avoid Linux). Apparently it's
> not even remotely portable.

Yeah. It's a monster. And tries to do all kind if stuff. Talk about
breaking the Unix paradigm...

Yes, I try to avoid Linux myself as well.

Johnny

On 2023-11-15 22:05, druck wrote:
> On 14/11/2023 09:30, Johnny Billquist wrote:
>> Source management is usually handled by one single program, even on
>> most systems today. Be that cvs, svn, git or whatever.
>
> git is actually a collection of programs, when you run
>
>     git command args
>
> it actually runs
>
>     git-command args
>
> You can even write your own git utilities, call them git-something and
> put them on PATH, and they will run when you do
>
>     git something

Yes. Some extensions are done that way. But the git binary itself is
reponsible for the most core things, like committing, pushing, pulling...

So no, there is no git-pull, no git-add, no git-merge and so on. But
there are some git-<command> binaries.

Maybe you could possibly call git a hybrid in this context.

Johnny

On Wednesday, November 15, 2023 at 1:00:40 PM UTC-8, Johnny Billquist wrote:
> On 2023-11-15 20:31, Jake Hamby (Solid State Jake) wrote:
> > On Wednesday, November 15, 2023 at 9:04:28 AM UTC-8, Richard Kettlewell wrote:
> >> Ahem A Rivet's Shot <ste...@eircom.net> writes:
> >>> Johnny Billquist <b...@softjar.se> wrote:
> >>>> Well. I don't fully agree with that, but I'm fine with just disagreeing
> >>>> without getting into any further discussions. I can certainly dig up
> >>>> other tools under Unix which left the "unix paradigm" behind a long time
> >>>> ago, if you want.
> >>>
> >>> Emacs springs to mind.
> >> Originated outside Unix, I think.
> >>
> >> dd seems like a good example. Present at least as far back as V5 Unix
> >> but its interface is belligerently different from any other Unix tool,
> >> and it’s at best an uneasy fit with the “do one thing well” approach of
> >> many of its siblings.
> >
> > The reason "dd" is so different from other UNIX tools is that it's a parody of the "DD" statement in IBM's JCL.
> Not sure it's meant as a parody. Don't even know what one would want to
> paridy such a thing. But I do remember seeing/hearing about it coming
> from some IBM thing.
>
> Johnny

Dennis Ritchie wrote that "dd was always named after JCL dd cards." https://unix.stackexchange.com/questions/712856/why-does-dd-use-in-its-parameters

The POSIX rationale says "Certainly, many of the operands could have been designed to use the Utility Syntax Guidelines, which would have resulted in the classic hyphenated option letters. In this version of this volume of POSIX.1-2017, dd retains its curious JCL-like syntax due to the large number of applications that depend on the historical implementation."

Whether you call it a parody or an homage, "dd" is 100% inspired by IBM's JCL.

In article <uj1tno$1lkjn$1@dont-email.me>,
Pancho <Pancho.Jones@proton.me> wrote:
>On 14/11/2023 23:58, Martin Gregorie wrote:
>> On Tue, 14 Nov 2023 15:24:59 -0500, Arne Vajhøj wrote:
>>
>> X> $ purge foobar.txt
>>>
>> Yes, I remember those periodic purges.
>>
>> I did like the customisable editor too and, IIRD, the ability to attach
>> customisations to file types. If there was an open source version of that
>> editor I might even be using it still.
>>
>
>If you mean EVE based on Vax/TPU it was ported to Unix, circa ~1995,
>SunOS, or possibly Solaris. So it is possible there is a version
>floating about.

It wasn't so much ported as rewritten from the bottom up when the
folks at Boston Business Computing released nu/TPU which was a
TPU-compatible package. It works really well, too.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

druck <news@druck.org.uk> writes:
> Johnny Billquist wrote:
>> Source management is usually handled by one single program, even on
>> most systems today. Be that cvs, svn, git or whatever.
>
> git is actually a collection of programs, when you run
>
> git command args
>
> it actually runs
>
> git-command args

Might have been once, but not any more.

$ strace -etrace=execve -f git clone whatever
execve("/usr/bin/git", ["git", "clone", "whatever"], 0x7fffeebfa9e0 /* 54 vars */) = 0
fatal: repository 'whatever' does not exist
+++ exited with 128 +++

> You can even write your own git utilities, call them git-something and
> put them on PATH, and they will run when you do
>
> git something

I think that remains true.

--
https://www.greenend.org.uk/rjk/