On 1/28/22 10:31 AM, Tauno Voipio wrote:
> On 28.1.22 13.26, The Natural Philosopher wrote:
>> On 28/01/2022 04:34, 3.BB963 wrote:
>>> On 1/27/22 7:57 AM, Falscher Bruce wrote:
>>>> I know all have vi, just wondering if another editor is standard issue.
>>>
>>>    It is becoming thus ... although some hard-asses STILL
>>>    think everybody should use vi "because THEY had to".
>>>    Screw vi - I remove/disable or in some cases use a
>>>    symlink so it starts nano instead. Nobody uses "edlin"
>>>    in Winders anymore and there's no reason to use
>>>    primitive line editors in Linux/BSD either. It'd be
>>>    like a country that can build sports-cars demanding
>>>    all their citizens ride donkeys.
>>
>> When I started out making Unix boxes do stuff, the ONLY editor that
>> was ALWAYS there was 'vi'.
>>
>> Since I still remember enough to make it usable, it's my default
>> console editor.
>> Familiarity wins over gruesomeness! :-)
>
> If we want to go back, we need to use 'ed'. 'vi' is an
> advanced version.

Oh yea, really "advanced" ... like donkeys are "advanced"
over just trudging across the tundra.

> 'ed' is the trusted editor to use with an ASR-33 TTY.
>
> I still vote for nano.

Nano gets it done. Vastly easier to cope with and only
a couple of control-sequences most ever need. I tend to
use it a lot - even in GUI environments.

And yes, you CAN edit sudoers with nano ... you just
have to do it right :-)

On 2022-01-28, The Natural Philosopher <tnp@invalid.invalid> wrote:
> When I started out making Unix boxes do stuff, the ONLY editor that was
> ALWAYS there was 'vi'.

Early on when I was working on Unix systems the big controversy was
over vi vs. ed. That namby-pamby visual editor was for lazy newbies.
Real Unix wizards used ed, preferably on an ASR-33 Teletype or DECwriter.

> Since I still remember enough to make it usable, it's my default console
> editor.
> Familiarity wins over gruesomeness! :-)

Indeed. I continue to use vi because I've been using it for something
like 40 years now and don't have to think about it, my fingers just
go on automatic. However I do not recommend it for new users.

--
------------------------------------------------------------------------------
18 Reasons I won't be vaccinated -- https://tinyurl.com/ebty2dx3
Covid vaccines: experimental biology -- https://tinyurl.com/57mncfm5
The fraud of "Climate Change" -- https://RealClimateScience.com
There is no "climate crisis" -- https://climatedepot.com
Don't talk to cops! -- https://DontTalkToCops.com
------------------------------------------------------------------------------

Am Samstag, 29. Januar 2022, um 02:08:22 Uhr schrieb Eli the Bearded:

> In comp.os.linux.misc, Marco Moock <mo01@posteo.de> wrote:
> > There are already Ubuntu docker containers that do not include vi,
> > but nano. This is PITA.
>
> I'm not doubting you, but that sure is weird. If you're going to strip
> down a container like that, why leave nano? Why even use Ubuntu
> instead of Alpine?

Because many (young) people hate vi/vim and want nano.
Using Ubuntu because the software inside works on Ubuntu and Ubuntu is
very common.

IIRC tt was this software:
https://helpcenter.onlyoffice.com/installation/docs-community-install-docker.aspx

> (And I wonder, is vi there in the form of busybox?)

I don't know, I didn't try that.

On 29/01/2022 04:02, Roger Blake wrote:
> On 2022-01-28, The Natural Philosopher <tnp@invalid.invalid> wrote:
>> When I started out making Unix boxes do stuff, the ONLY editor that was
>> ALWAYS there was 'vi'.
>
> Early on when I was working on Unix systems the big controversy was
> over vi vs. ed. That namby-pamby visual editor was for lazy newbies.
> Real Unix wizards used ed, preferably on an ASR-33 Teletype or DECwriter.
>
>> Since I still remember enough to make it usable, it's my default console
>> editor.
>> Familiarity wins over gruesomeness! :-)
>
> Indeed. I continue to use vi because I've been using it for something
> like 40 years now and don't have to think about it, my fingers just
> go on automatic. However I do not recommend it for new users.
>
+1.

--
New Socialism consists essentially in being seen to have your heart in
the right place whilst your head is in the clouds and your hand is in
someone else's pocket.

Am Samstag, 29. Januar 2022, um 04:02:15 Uhr schrieb Roger Blake:

> On 2022-01-28, The Natural Philosopher <tnp@invalid.invalid> wrote:
> > When I started out making Unix boxes do stuff, the ONLY editor that
> > was ALWAYS there was 'vi'.
>
> Early on when I was working on Unix systems the big controversy was
> over vi vs. ed. That namby-pamby visual editor was for lazy newbies.
> Real Unix wizards used ed, preferably on an ASR-33 Teletype or
> DECwriter.
>
> > Since I still remember enough to make it usable, it's my default
> > console editor.
> > Familiarity wins over gruesomeness! :-)
>
> Indeed. I continue to use vi because I've been using it for something
> like 40 years now and don't have to think about it, my fingers just
> go on automatic. However I do not recommend it for new users.

I started using vim in 2018 and I don't want to miss it. I can do many
things much faster. I also recommend it to new users, but the need to
be aware that they need to invest time to learn it.

On Friday, January 28, 2022 at 1:29:08 AM UTC+8, Jeremy Brubaker wrote:

> I was working on a VPS the other day that was running CentOS and it
> didn't even have vi(1) installed. To avoid having to use scp to copy
> files down so I could edit them just to copy them back up I used sed(1).
>

WTF? Centos would be mainly on pizza boxes, so I would expect no GUI editors, but no vi?????

On Fri, 28 Jan 2022 21:34:37 -0500, "3.BB963" <z24ba74.net> wrote:
>
> On 1/28/22 3:24 PM, Diego Garcia wrote:
>> On Thu, 27 Jan 2022 23:34:11 -0500, 3.BB963 wrote:
>>
>> Ed, for example, is used in shell scripts, and I suppose
>> that this is the main reason for keeing it around.
>
> Past time to update those old scripts then ...

That'll be a too large overhaul.

I see no reason why, since users don't work on these scripts. The system does.
--
Andreas

On Sat, 29 Jan 2022 04:02:15 -0000 (UTC), Roger Blake wrote:
>
> Early on when I was working on Unix systems the big controversy was
> over vi vs. ed. That namby-pamby visual editor was for lazy newbies.
> Real Unix wizards used ed, preferably on an ASR-33 Teletype or DECwriter.

And then Emacs came along, and even brought a church in. ;-)
--
Andreas

On 2022-01-29, Andreas Kohlbach <ank@spamfence.net> wrote:
> On Sat, 29 Jan 2022 04:02:15 -0000 (UTC), Roger Blake wrote:
>
> And then Emacs came along, and even brought a church in. ;-)

And even a doctor!

On 1/29/22 9:16 AM, Andreas Kohlbach wrote:
> On Fri, 28 Jan 2022 21:34:37 -0500, "3.BB963" <z24ba74.net> wrote:
>>
>> On 1/28/22 3:24 PM, Diego Garcia wrote:
>>> On Thu, 27 Jan 2022 23:34:11 -0500, 3.BB963 wrote:
>>>
>>> Ed, for example, is used in shell scripts, and I suppose
>>> that this is the main reason for keeing it around.
>>
>> Past time to update those old scripts then ...
>
> That'll be a too large overhaul.
>
> I see no reason why, since users don't work on these scripts. The system does.

Mostly, yes ... but I hate to see obsolete code lurking
around. Oh, and basically hacks would only need to
contaminate vi without anybody noticing - and it's so
old I bet nobody looks - in order to do horrendous
damage.

WAY back in the day, when Regular Humans first started to
get their hands on good computers - latter 60s/early 70s -
there was a sort of game that went on. The goal was to
devise ways to do common little tasks using less bytes/
cycles than the last winner. Sometimes these tricks were
particular to some cpu architecture (oft PDP-11) but
many were more general. Some are SO tricky that you
REALLY have to think about why they work at all - weaves
of XORs/ANDs/ORs/NANDS and byte/word overflows. Might
related to date/time calx or how mem is allocated or
how devices are abstracted. All sorts of tricks were
devised. Bill Gates was a significant player, and
was very good BTW (I'll question his ethics but never
his coding skills).

The thing is, these tricky code hacks did NOT go away,
they are now built into EVERYTHING - copy & paste. Code
so old nobody even bothers to think about it. Tweak
them just a tad directly, or the environment they expect,
and you can do a lot of harm very easily.

I have a weird gift (which has been profitible) ... I have
an instinct for how things can go WRONG. Any pgm I write
for humans is usually a quarter or third code dealing with
everything a Stupid Human could possibly do wrong. And what
if the file you were writing to a millisecond ago suddenly
can't be written to - do you throw an error, buffer, or put
it all in a concurrent process with retries or what ?
Reality is just MESSY and the compuscape is now too HUGE
to fully evaluate - and too many hacks know how to take
full advantage of that.

On 1/28/22 11:02 PM, Roger Blake wrote:
> On 2022-01-28, The Natural Philosopher <tnp@invalid.invalid> wrote:
>> When I started out making Unix boxes do stuff, the ONLY editor that was
>> ALWAYS there was 'vi'.
>
> Early on when I was working on Unix systems the big controversy was
> over vi vs. ed. That namby-pamby visual editor was for lazy newbies.
> Real Unix wizards used ed, preferably on an ASR-33 Teletype or DECwriter.
>
>> Since I still remember enough to make it usable, it's my default console
>> editor.
>> Familiarity wins over gruesomeness! :-)
>
> Indeed. I continue to use vi because I've been using it for something
> like 40 years now and don't have to think about it, my fingers just
> go on automatic. However I do not recommend it for new users.

Servilan is looking for you ...

Such obsolete notions :-)

On Sun, 30 Jan 2022 00:56:47 -0500, "3.BB963" <z24ba74.net> wrote:
>
> On 1/29/22 9:16 AM, Andreas Kohlbach wrote:
>> On Fri, 28 Jan 2022 21:34:37 -0500, "3.BB963" <z24ba74.net> wrote:
>>>
>>> On 1/28/22 3:24 PM, Diego Garcia wrote:
>>>> On Thu, 27 Jan 2022 23:34:11 -0500, 3.BB963 wrote:
>>>>
>>>> Ed, for example, is used in shell scripts, and I suppose
>>>> that this is the main reason for keeing it around.
>>>
>>> Past time to update those old scripts then ...
>> That'll be a too large overhaul.
>> I see no reason why, since users don't work on these scripts. The
>> system does.
>
> Mostly, yes ... but I hate to see obsolete code lurking
> around. Oh, and basically hacks would only need to
> contaminate vi without anybody noticing - and it's so
> old I bet nobody looks - in order to do horrendous
> damage.

Unless there is a bug detected (soon to be fixed then anyway) in ED,
moving all scripts to something more modern is economically not feasible.

I agree, *new* scripts should *not* use ed anymore. But unless someone is
really bored, and replaces the use of ed in hundreds or more of old "system
scripts" with something else, leave ED alone.

Btw. I hate ed too, as I hate edlin in MS-DOS.

But I also love "pain". Some time ago I looked into CP/M to run it in an
emulator for the Osborne I computer. It comes with another painful
editor named ED, similar to edlin.
--
Andreas

On 30.1.22 18.42, Andreas Kohlbach wrote:
> On Sun, 30 Jan 2022 00:56:47 -0500, "3.BB963" <z24ba74.net> wrote:
>>
>> On 1/29/22 9:16 AM, Andreas Kohlbach wrote:
>>> On Fri, 28 Jan 2022 21:34:37 -0500, "3.BB963" <z24ba74.net> wrote:
>>>>
>>>> On 1/28/22 3:24 PM, Diego Garcia wrote:
>>>>> On Thu, 27 Jan 2022 23:34:11 -0500, 3.BB963 wrote:
>>>>>
>>>>> Ed, for example, is used in shell scripts, and I suppose
>>>>> that this is the main reason for keeing it around.
>>>>
>>>> Past time to update those old scripts then ...
>>> That'll be a too large overhaul.
>>> I see no reason why, since users don't work on these scripts. The
>>> system does.
>>
>> Mostly, yes ... but I hate to see obsolete code lurking
>> around. Oh, and basically hacks would only need to
>> contaminate vi without anybody noticing - and it's so
>> old I bet nobody looks - in order to do horrendous
>> damage.
>
> Unless there is a bug detected (soon to be fixed then anyway) in ED,
> moving all scripts to something more modern is economically not feasible.
>
> I agree, *new* scripts should *not* use ed anymore. But unless someone is
> really bored, and replaces the use of ed in hundreds or more of old "system
> scripts" with something else, leave ED alone.
>
> Btw. I hate ed too, as I hate edlin in MS-DOS.
>
> But I also love "pain". Some time ago I looked into CP/M to run it in an
> emulator for the Osborne I computer. It comes with another painful
> editor named ED, similar to edlin.

Both UNIX ed and CP/M ED are based on an editor from DEC for PDP-11,
named ED.

--

-TV

On 30/01/2022 16:42, Andreas Kohlbach wrote:
> On Sun, 30 Jan 2022 00:56:47 -0500, "3.BB963" <z24ba74.net> wrote:
>>
>> On 1/29/22 9:16 AM, Andreas Kohlbach wrote:
>>> On Fri, 28 Jan 2022 21:34:37 -0500, "3.BB963" <z24ba74.net> wrote:
>>>>
>>>> On 1/28/22 3:24 PM, Diego Garcia wrote:
>>>>> On Thu, 27 Jan 2022 23:34:11 -0500, 3.BB963 wrote:
>>>>>
>>>>> Ed, for example, is used in shell scripts, and I suppose
>>>>> that this is the main reason for keeing it around.
>>>>
>>>> Past time to update those old scripts then ...
>>> That'll be a too large overhaul.
>>> I see no reason why, since users don't work on these scripts. The
>>> system does.
>>
>> Mostly, yes ... but I hate to see obsolete code lurking
>> around. Oh, and basically hacks would only need to
>> contaminate vi without anybody noticing - and it's so
>> old I bet nobody looks - in order to do horrendous
>> damage.
>
> Unless there is a bug detected (soon to be fixed then anyway) in ED,
> moving all scripts to something more modern is economically not feasible.
>
> I agree, *new* scripts should *not* use ed anymore. But unless someone is
> really bored, and replaces the use of ed in hundreds or more of old "system
> scripts" with something else, leave ED alone.
>
> Btw. I hate ed too, as I hate edlin in MS-DOS.
>
> But I also love "pain". Some time ago I looked into CP/M to run it in an
> emulator for the Osborne I computer. It comes with another painful
> editor named ED, similar to edlin.

Wordstar was extensively pirated onto it.

--
If I had all the money I've spent on drink...
...I'd spend it on drink.

Sir Henry (at Rawlinson's End)

On 2022-01-29, Roger Blake <rogblake@iname.invalid> wrote:
> On 2022-01-28, The Natural Philosopher <tnp@invalid.invalid> wrote:
>> When I started out making Unix boxes do stuff, the ONLY editor that was
>> ALWAYS there was 'vi'.
>
> Early on when I was working on Unix systems the big controversy was
> over vi vs. ed. That namby-pamby visual editor was for lazy newbies.
> Real Unix wizards used ed, preferably on an ASR-33 Teletype or DECwriter.
>
>> Since I still remember enough to make it usable, it's my default console
>> editor.
>> Familiarity wins over gruesomeness! :-)
>
> Indeed. I continue to use vi because I've been using it for something
> like 40 years now and don't have to think about it, my fingers just
> go on automatic. However I do not recommend it for new users.
>

While off the OP's topic, same goes for me with my use of Joe in its jstar
incarnation.

My fingers just know the WordStar commands on automatic.

I do, however, have to insall Joe on every distro I install and have no
idea, really, what's installed by default.

I see the emacs/vi wars have subsided...no emacs warriors commenting here.

pH

ps: Thanks for the links in your sig, by the way.

On 2022-01-30, Andreas Kohlbach <ank@spamfence.net> wrote:

> On Sun, 30 Jan 2022 00:56:47 -0500, "3.BB963" <z24ba74.net> wrote:
>
>> On 1/29/22 9:16 AM, Andreas Kohlbach wrote:
>>
>>> On Fri, 28 Jan 2022 21:34:37 -0500, "3.BB963" <z24ba74.net> wrote:
>>>>
>>>> On 1/28/22 3:24 PM, Diego Garcia wrote:
>>>>
>>>>> Ed, for example, is used in shell scripts, and I suppose
>>>>> that this is the main reason for keeing it around.
>>>>
>>>> Past time to update those old scripts then ...
>>>
>>> That'll be a too large overhaul.
>>> I see no reason why, since users don't work on these scripts.
>>> The system does.
>>
>> Mostly, yes ... but I hate to see obsolete code lurking
>> around. Oh, and basically hacks would only need to
>> contaminate vi without anybody noticing - and it's so
>> old I bet nobody looks - in order to do horrendous
>> damage.
>
> Unless there is a bug detected (soon to be fixed then anyway) in ED,
> moving all scripts to something more modern is economically not feasible.
>
> I agree, *new* scripts should *not* use ed anymore. But unless someone is
> really bored, and replaces the use of ed in hundreds or more of old "system
> scripts" with something else, leave ED alone.
>
> Btw. I hate ed too, as I hate edlin in MS-DOS.
>
> But I also love "pain". Some time ago I looked into CP/M to run it in
> an emulator for the Osborne I computer. It comes with another painful
> editor named ED, similar to edlin.

I discovered that edlin is sufficiently similar to CP/M's ed that
you could pick it up easily - but sufficiently different that you
got bitten from time to time. No shortage of pain...

--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.

On 2022-01-30, 3.BB963 <z24ba74.net> wrote:

> On 1/29/22 9:16 AM, Andreas Kohlbach wrote:
>
>> On Fri, 28 Jan 2022 21:34:37 -0500, "3.BB963" <z24ba74.net> wrote:
>>>
>>> On 1/28/22 3:24 PM, Diego Garcia wrote:
>>>
>>>> Ed, for example, is used in shell scripts, and I suppose
>>>> that this is the main reason for keeing it around.
>>>
>>> Past time to update those old scripts then ...
>>
>> That'll be a too large overhaul.
>>
>> I see no reason why, since users don't work on these scripts.
>> The system does.
>
> Mostly, yes ... but I hate to see obsolete code lurking
> around. Oh, and basically hacks would only need to
> contaminate vi without anybody noticing - and it's so
> old I bet nobody looks - in order to do horrendous
> damage.
>
> WAY back in the day, when Regular Humans first started to
> get their hands on good computers - latter 60s/early 70s -
> there was a sort of game that went on. The goal was to
> devise ways to do common little tasks using less bytes/
> cycles than the last winner. Sometimes these tricks were
> particular to some cpu architecture (oft PDP-11) but
> many were more general. Some are SO tricky that you
> REALLY have to think about why they work at all - weaves
> of XORs/ANDs/ORs/NANDS and byte/word overflows. Might
> related to date/time calx or how mem is allocated or
> how devices are abstracted. All sorts of tricks were
> devised. Bill Gates was a significant player, and
> was very good BTW (I'll question his ethics but never
> his coding skills).

Heck, in those days we all had to learn those tricks. If
you're trying to run payroll in a machine with 16K of memory,
you have to find ways to squeeze code. My beef with Windows -
and MS-DOS before it - is all their horrible design decisions
that went into them. For example, why should COPY refuse to
copy a zero-length file - but still delete an output file of
the same name before quitting? I could go on for hours about
the time I've spent working around some of these bugs...
err, features - and for this reason I'll never see Bill Gates
as more than a mediocre programmer. The rest of us moved on.

> The thing is, these tricky code hacks did NOT go away,
> they are now built into EVERYTHING - copy & paste. Code
> so old nobody even bothers to think about it. Tweak
> them just a tad directly, or the environment they expect,
> and you can do a lot of harm very easily.

This is sometimes known as "cargo-cult programming".
The consequences are predictable.

> I have a weird gift (which has been profitible) ... I have
> an instinct for how things can go WRONG. Any pgm I write
> for humans is usually a quarter or third code dealing with
> everything a Stupid Human could possibly do wrong. And what
> if the file you were writing to a millisecond ago suddenly
> can't be written to - do you throw an error, buffer, or put
> it all in a concurrent process with retries or what ?
> Reality is just MESSY and the compuscape is now too HUGE
> to fully evaluate - and too many hacks know how to take
> full advantage of that.

I'm the same way. It's easy to write a program that works under
perfect conditions - but writing something that will stay up
under Real World conditions is another level altogether.

--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.

In comp.os.linux.misc, Marco Moock <mo01@posteo.de> wrote:
> Am Samstag, 29. Januar 2022, um 02:08:22 Uhr schrieb Eli the Bearded:
>> I'm not doubting you, but that sure is weird. If you're going to strip
>> down a container like that, why leave nano? Why even use Ubuntu
>> instead of Alpine?
> Because many (young) people hate vi/vim and want nano.

Yeah, that's a different issue. Most people don't ever run an editor
inside a container. People configure files outside, run `docker build`
and `docker run` and have their (relatively) sealed container.

To use vi/nano/ed/whatever inside the container requires a special
connection: `docker exec -it image /bin/sh` then starting up the
next program.

Stripping out anything you don't need inside the container makes for
a smaller disk overlay. And you need very little, so you can strip out
an awful lot (see Alpine). Even a small container is pretty large
compared to a program file, so it's good practice to start with very
little inside.

> Using Ubuntu because the software inside works on Ubuntu and Ubuntu is
> very common.

Yeah, but I was under the impression that vim-tiny was part of the
default "minimal" install of Ubuntu.

> IIRC tt was this software:
> https://helpcenter.onlyoffice.com/installation/docs-community-install-docker.aspx

Yeah, that's the sort of thing where "Why are you even looking for an
editor inside the container?"

>> (And I wonder, is vi there in the form of busybox?)
> I don't know, I didn't try that.

Pretty sure "/usr/bin/busybox" with "busybox vi" is also in minimal
install. (Busybox can be compiled to not have vi, so that's a risk.)

Elijah
------
has been saved by busybox before

On 1/30/22 12:25 PM, Tauno Voipio wrote:
> On 30.1.22 18.42, Andreas Kohlbach wrote:
>> On Sun, 30 Jan 2022 00:56:47 -0500, "3.BB963" <z24ba74.net> wrote:
>>>
>>> On 1/29/22 9:16 AM, Andreas Kohlbach wrote:
>>>> On Fri, 28 Jan 2022 21:34:37 -0500, "3.BB963" <z24ba74.net> wrote:
>>>>>
>>>>> On 1/28/22 3:24 PM, Diego Garcia wrote:
>>>>>> On Thu, 27 Jan 2022 23:34:11 -0500, 3.BB963 wrote:
>>>>>>
>>>>>> Ed, for example, is used in shell scripts, and I suppose
>>>>>> that this is the main reason for keeing it around.
>>>>>
>>>>>     Past time to update those old scripts then ...
>>>> That'll be a too large overhaul.
>>>> I see no reason why, since users don't work on these scripts. The
>>>> system does.
>>>
>>>    Mostly, yes ... but I hate to see obsolete code lurking
>>>    around. Oh, and basically hacks would only need to
>>>    contaminate vi without anybody noticing - and it's so
>>>    old I bet nobody looks - in order to do horrendous
>>>    damage.
>>
>> Unless there is a bug detected (soon to be fixed then anyway) in ED,
>> moving all scripts to something more modern is economically not feasible.
>>
>> I agree, *new* scripts should *not* use ed anymore. But unless someone is
>> really bored, and replaces the use of ed in hundreds or more of old
>> "system
>> scripts" with something else, leave ED alone.
>>
>> Btw. I hate ed too, as I hate edlin in MS-DOS.
>>
>> But I also love "pain". Some time ago I looked into CP/M to run it in an
>> emulator for the Osborne I computer. It comes with another painful
>> editor named ED, similar to edlin.
>
>
> Both UNIX ed and CP/M ED are based on an editor from DEC for PDP-11,
> named ED.

I had a tiny amount of experience with a PDP-11 ..
and I just HATED "ED" :-)

There had to be a better way ... and it wasn't long
before people found some.

On 1/30/22 1:52 PM, Charlie Gibbs wrote:
> On 2022-01-30, 3.BB963 <z24ba74.net> wrote:
>
>> On 1/29/22 9:16 AM, Andreas Kohlbach wrote:
>>
>>> On Fri, 28 Jan 2022 21:34:37 -0500, "3.BB963" <z24ba74.net> wrote:
>>>>
>>>> On 1/28/22 3:24 PM, Diego Garcia wrote:
>>>>
>>>>> Ed, for example, is used in shell scripts, and I suppose
>>>>> that this is the main reason for keeing it around.
>>>>
>>>> Past time to update those old scripts then ...
>>>
>>> That'll be a too large overhaul.
>>>
>>> I see no reason why, since users don't work on these scripts.
>>> The system does.
>>
>> Mostly, yes ... but I hate to see obsolete code lurking
>> around. Oh, and basically hacks would only need to
>> contaminate vi without anybody noticing - and it's so
>> old I bet nobody looks - in order to do horrendous
>> damage.
>>
>> WAY back in the day, when Regular Humans first started to
>> get their hands on good computers - latter 60s/early 70s -
>> there was a sort of game that went on. The goal was to
>> devise ways to do common little tasks using less bytes/
>> cycles than the last winner. Sometimes these tricks were
>> particular to some cpu architecture (oft PDP-11) but
>> many were more general. Some are SO tricky that you
>> REALLY have to think about why they work at all - weaves
>> of XORs/ANDs/ORs/NANDS and byte/word overflows. Might
>> related to date/time calx or how mem is allocated or
>> how devices are abstracted. All sorts of tricks were
>> devised. Bill Gates was a significant player, and
>> was very good BTW (I'll question his ethics but never
>> his coding skills).
>
> Heck, in those days we all had to learn those tricks. If
> you're trying to run payroll in a machine with 16K of memory,
> you have to find ways to squeeze code. My beef with Windows -
> and MS-DOS before it - is all their horrible design decisions
> that went into them. For example, why should COPY refuse to
> copy a zero-length file - but still delete an output file of
> the same name before quitting? I could go on for hours about
> the time I've spent working around some of these bugs...
> err, features - and for this reason I'll never see Bill Gates
> as more than a mediocre programmer. The rest of us moved on.
>
>> The thing is, these tricky code hacks did NOT go away,
>> they are now built into EVERYTHING - copy & paste. Code
>> so old nobody even bothers to think about it. Tweak
>> them just a tad directly, or the environment they expect,
>> and you can do a lot of harm very easily.
>
> This is sometimes known as "cargo-cult programming".
> The consequences are predictable.
>
>> I have a weird gift (which has been profitible) ... I have
>> an instinct for how things can go WRONG. Any pgm I write
>> for humans is usually a quarter or third code dealing with
>> everything a Stupid Human could possibly do wrong. And what
>> if the file you were writing to a millisecond ago suddenly
>> can't be written to - do you throw an error, buffer, or put
>> it all in a concurrent process with retries or what ?
>> Reality is just MESSY and the compuscape is now too HUGE
>> to fully evaluate - and too many hacks know how to take
>> full advantage of that.
>
> I'm the same way. It's easy to write a program that works under
> perfect conditions - but writing something that will stay up
> under Real World conditions is another level altogether.

It would be interesting to see what percentage of
commercial software is dedicated to countering
everything Stupid Humans and balky hardware can
possibly do to screw things up ...

On 31/01/2022 06:24, 3.BB963 wrote:
> On 1/30/22 1:52 PM, Charlie Gibbs wrote:
>> On 2022-01-30, 3.BB963 <z24ba74.net> wrote:
>>
>>> On 1/29/22 9:16 AM, Andreas Kohlbach wrote:
>>>
>>>> On Fri, 28 Jan 2022 21:34:37 -0500, "3.BB963" <z24ba74.net> wrote:
>>>>>
>>>>> On 1/28/22 3:24 PM, Diego Garcia wrote:
>>>>>
>>>>>> Ed, for example, is used in shell scripts, and I suppose
>>>>>> that this is the main reason for keeing it around.
>>>>>
>>>>> Past time to update those old scripts then ...
>>>>
>>>> That'll be a too large overhaul.
>>>>
>>>> I see no reason why, since users don't work on these scripts.
>>>> The system does.
>>>
>>>     Mostly, yes ... but I hate to see obsolete code lurking
>>>     around. Oh, and basically hacks would only need to
>>>     contaminate vi without anybody noticing - and it's so
>>>     old I bet nobody looks - in order to do horrendous
>>>     damage.
>>>
>>>     WAY back in the day, when Regular Humans first started to
>>>     get their hands on good computers - latter 60s/early 70s -
>>>     there was a sort of game that went on. The goal was to
>>>     devise ways to do common little tasks using less bytes/
>>>     cycles than the last winner. Sometimes these tricks were
>>>     particular to some cpu architecture (oft PDP-11) but
>>>     many were more general. Some are SO tricky that you
>>>     REALLY have to think about why they work at all - weaves
>>>     of XORs/ANDs/ORs/NANDS and byte/word overflows. Might
>>>     related to date/time calx or how mem is allocated or
>>>     how devices are abstracted. All sorts of tricks were
>>>     devised. Bill Gates was a significant player, and
>>>     was very good BTW (I'll question his ethics but never
>>>     his coding skills).
>>
>> Heck, in those days we all had to learn those tricks.  If
>> you're trying to run payroll in a machine with 16K of memory,
>> you have to find ways to squeeze code.  My beef with Windows -
>> and MS-DOS before it - is all their horrible design decisions
>> that went into them.  For example, why should COPY refuse to
>> copy a zero-length file - but still delete an output file of
>> the same name before quitting?  I could go on for hours about
>> the time I've spent working around some of these bugs...
>> err, features - and for this reason I'll never see Bill Gates
>> as more than a mediocre programmer.  The rest of us moved on.
>>
>>>     The thing is, these tricky code hacks did NOT go away,
>>>     they are now built into EVERYTHING - copy & paste. Code
>>>     so old nobody even bothers to think about it. Tweak
>>>     them just a tad directly, or the environment they expect,
>>>     and you can do a lot of harm very easily.
>>
>> This is sometimes known as "cargo-cult programming".
>> The consequences are predictable.
>>
>>>     I have a weird gift (which has been profitible) ... I have
>>>     an instinct for how things can go WRONG. Any pgm I write
>>>     for humans is usually a quarter or third code dealing with
>>>     everything a Stupid Human could possibly do wrong. And what
>>>     if the file you were writing to a millisecond ago suddenly
>>>     can't be written to - do you throw an error, buffer, or put
>>>     it all in a concurrent process with retries or what ?
>>>     Reality is just MESSY and the compuscape is now too HUGE
>>>     to fully evaluate - and too many hacks know how to take
>>>     full advantage of that.
>>
>> I'm the same way.  It's easy to write a program that works under
>> perfect conditions - but writing something that will stay up
>> under Real World conditions is another level altogether.
>
>   It would be interesting to see what percentage of
>   commercial software is dedicated to countering
>   everything Stupid Humans and balky hardware can
>   possibly do to screw things up ...
>
One piece of code I wrote was 70% exception processing.

--
"The great thing about Glasgow is that if there's a nuclear attack it'll
look exactly the same afterwards."

Billy Connolly

On Mon, 31 Jan 2022 01:21:28 -0500, "3.BB963" <z24ba74.net> wrote:
>
> On 1/30/22 12:25 PM, Tauno Voipio wrote:
>
> I had a tiny amount of experience with a PDP-11 ..
> and I just HATED "ED" :-)
>
> There had to be a better way ... and it wasn't long
> before people found some.

I think the problem was having not enough RAM available for even loading
a text file. The editor would load only a few lines into RAM at every
given time.

Only when in the 1980s machines with an abundance of memory (like 64 KB :-)
hit the markets, some text files could be held in RAM.

The Commodore 64 for example. It can display 40 characters per line, with
25 lines. Each character is one byte. That's 1 KB only for the
screen. Older machines might only had 4 KB RAM in total, 1 reserved for
the screen, so you start with less than 3 KB. Your program (a text
editor) has a certain size. There is no space left to keep a complete
(longer than a few bytes) text file in RAM.
--
Andreas

On Sun, 30 Jan 2022 17:35:10 +0000, The Natural Philosopher wrote:
>
> On 30/01/2022 16:42, Andreas Kohlbach wrote:
>> On Sun, 30 Jan 2022 00:56:47 -0500, "3.BB963" <z24ba74.net> wrote:
>
>> Unless there is a bug detected (soon to be fixed then anyway) in ED,
>> moving all scripts to something more modern is economically not feasible.
>> I agree, *new* scripts should *not* use ed anymore. But unless
>> someone is
>> really bored, and replaces the use of ed in hundreds or more of old "system
>> scripts" with something else, leave ED alone.
>> Btw. I hate ed too, as I hate edlin in MS-DOS.
>> But I also love "pain". Some time ago I looked into CP/M to run it
>> in an
>> emulator for the Osborne I computer. It comes with another painful
>> editor named ED, similar to edlin.
>
> Wordstar was extensively pirated onto it.

It came with a complete office suite, including Wordstar. Next to a
spreadsheet and database program it came with two flavors of BASIC and a
few games. The suite is (or was, cannot find it right now) available at
archive.org (that's where I got my version from).

As limit the Osborne didn't have cursor keys. One had to learn to use the
"Wordstar Diamond".
--
Andreas

On Sun, 30 Jan 2022 18:43:30 -0000 (UTC), pH wrote:
>
> While off the OP's topic, same goes for me with my use of Joe in its jstar
> incarnation.

"Wordstar Diamond"?
--
Andreas

On 30.1.22 20.43, pH wrote:
> On 2022-01-29, Roger Blake <rogblake@iname.invalid> wrote:
>> On 2022-01-28, The Natural Philosopher <tnp@invalid.invalid> wrote:
>>> When I started out making Unix boxes do stuff, the ONLY editor that was
>>> ALWAYS there was 'vi'.
>>
>> Early on when I was working on Unix systems the big controversy was
>> over vi vs. ed. That namby-pamby visual editor was for lazy newbies.
>> Real Unix wizards used ed, preferably on an ASR-33 Teletype or DECwriter.
>>
>>> Since I still remember enough to make it usable, it's my default console
>>> editor.
>>> Familiarity wins over gruesomeness! :-)
>>
>> Indeed. I continue to use vi because I've been using it for something
>> like 40 years now and don't have to think about it, my fingers just
>> go on automatic. However I do not recommend it for new users.
>>
>
> While off the OP's topic, same goes for me with my use of Joe in its jstar
> incarnation.
>
> My fingers just know the WordStar commands on automatic.
>
> I do, however, have to insall Joe on every distro I install and have no
> idea, really, what's installed by default.
>
> I see the emacs/vi wars have subsided...no emacs warriors commenting here.
>
> pH
>
>
> ps: Thanks for the links in your sig, by the way.
>

Comparing Emacs to VI is a bit like comparing a wheelbarrow and
a truck/lorry. Emacs is far too bulky to be squeezed into any small
configuration.

--

-TV