From Newsgroup: comp.unix.shell

ed is the standard text editor.
right now, i am using ed to edit this post!
nvim is based on vim is based on vi is based on ex is based on ed
sed and grep are also based off of ed
ed was created from qed (from which sed takes some extra commands not in
ed!)
ed was created by ken thompsom and dennis ritchie
https://x.com/ed1conf
https://linux.die.net/man/1/ed
https://wiki.c2.com/?EdIsTheStandardTextEditor https://en.wikipedia.org/wiki/Ed_(text_editor)
ed, man! !man ed (or i guess really !info ed)
using ed is a little like using a shell.
first show the prompt (optional) by typing P and hitting enter.
now, here are some commands than can be ran in ed:
[type a number] - go to that line number (1 is first line)
a - append text in lines after the line you were on
to stop appending, type a single period in a line by itself, and hit ent
er.
you can put a line number before a command to go there before running it
.
. can also stand for a line number to mean the current line you are on.
[line number],[line number]d - deleter text from the first to second lin
e number inclusive.
e - chooses a file to edit
p - print the line you are on in case you forgot
! - runs a command.
you can use ! to edit the file you are inside by using %.
e.g. !fold -n 67 %
you can also use it with e: e !ncal
r - like e, buts appends instead of replaces
= - shows how many lines there are in the file.
you can put . before it to show what line number you are currently on. (
.=)
s/regex/regex/ - substitutes the first instances of the first regex's ma
tch
with the second one. this command is used a lot in grep and sed, so it m
ay seem familiar.
newline by itself - go to the next line and print it (like the more comm
and)
these are just a few commands in ed. the see them all, along with more h
elp,
simply run `info ed'!
i think that's all.
reply here if you use ed and would like to talk about it, or if your nam
e is ed!
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2026-06-08 04:16, Zayd Mohammed wrote:

ed is the standard text editor.

'ed' is _a_ standard text editor; on Unixes. Though a very primitive
one.

right now, i am using ed to edit this post!

(I wonder why one would make ones life harder than necessary.)

Is that the reason why the formatting of your post is corrupt?
(Or is it your newsreader settings?)

nvim is based on vim is based on vi is based on ex is based on ed

I think "based on" may be a misleading formulation here.

Vim is not based on the Vi code base. But functionally yes, mostly.
And you won't gain anything if trying to somehow relate Vim to Ed;
these are functionally completely different things.

Maybe modulo the very first beginning (when vi was added to ex as a
visual mode) mode, ex and vi are just two modes of the same editor.

[...]

reply here if you use ed and would like to talk about it, or if your nam
e is ed!

I suggest to talk about editors in comp.editors (not primarily here).

Janis

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

In article <1105ae4$1naub$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

On 2026-06-08 04:16, Zayd Mohammed wrote:

ed is the standard text editor.

'ed' is _a_ standard text editor; on Unixes. Though a very primitive
one.

Saying, "`ed` is the standard text editor" on Unix systems is an
old joke.

- Dan C.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

In article <1106h0l$lb$1@reader1.panix.com>,
Dan Cross <cross@spitfire.i.gajendra.net> wrote:

In article <1105ae4$1naub$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

On 2026-06-08 04:16, Zayd Mohammed wrote:

ed is the standard text editor.

'ed' is _a_ standard text editor; on Unixes. Though a very primitive
one.

Saying, "`ed` is the standard text editor" on Unix systems is an
old joke.

Indeed. And the joke works better if you base it on and sing it to the
tune of "Mr Ed".
--
The randomly chosen signature file that would have appeared here is more than 4-ish
lines long. As such, it violates one or more Usenet RFCs. In order to remain in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/LadyChatterley
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

In article <1106ijl$1h9mu$1@news.xmission.com>,
Kenny McCormack <gazelle@shell.xmission.com> wrote:

In article <1106h0l$lb$1@reader1.panix.com>,
Dan Cross <cross@spitfire.i.gajendra.net> wrote:

In article <1105ae4$1naub$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

On 2026-06-08 04:16, Zayd Mohammed wrote:

ed is the standard text editor.

'ed' is _a_ standard text editor; on Unixes. Though a very primitive
one.

Saying, "`ed` is the standard text editor" on Unix systems is an
old joke.

Indeed. And the joke works better if you base it on and sing it to the
tune of "Mr Ed".

(Those in the know refer to it as e-d, pronounced "ee dee", not
"Ed" as in the short form of Edward. :-))

- Dan C.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

cross@spitfire.i.gajendra.net (Dan Cross) writes:

In article <1105ae4$1naub$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

On 2026-06-08 04:16, Zayd Mohammed wrote:

ed is the standard text editor.

'ed' is _a_ standard text editor; on Unixes. Though a very primitive
one.

Saying, "`ed` is the standard text editor" on Unix systems is an
old joke.

I recall that some versions of the ed(1) man page started with
"ed is the standard text editor".

I can't find that line on any system I have access to, or anywhere
in the history of GNU ed (which is of course not the original ed),
but a web search turns it up as a line from old man pages.
The current GNU ed man page says:

Ed is the rCOstandardrCO text editor in the sense that it is the
original editor for Unix, and thus widely available. For most
purposes, however, it is superseded by full-screen editors.

which is an implicit reference to the old wording.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

Zayd Mohammed <zaydm@172.24.208.1> wrote:

ed is the standard text editor.

<snip>

Surprised no one posted this old link :)

https://www.gnu.org/fun/jokes/ed-msg.html
--
[t]csh(1) - "An elegant shell, for a more... civilized age."
- Paraphrasing Star Wars
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

In article <1107cro$3hr0r$1@kst.eternal-september.org>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

I recall that some versions of the ed(1) man page started with
"ed is the standard text editor".

<URL:https://man.freebsd.org/cgi/man.cgi?query=ed&apropos=0&sektion=0&manpath=Unix+Seventh+Edition&format=html>
| Ed is the standard text editor.

John
groenveld@acm.org
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

I recall that some versions of the ed(1) man page started with "ed is
the standard text editor". [...] a web search turns it up as a line
from old man pages.

Very old man pages -- it's had that wording since Unix V1:
http://squoze.net/UNIX/v1man/man1/ed

Because the early Unix manuals are often influenced by CTSS and Multics,
I was curious as to whether similar wording showed up anywhere else. The
1973 Multics Programmer's Manual (revision 14) says:

The two standard editors are named edm and qedx.

And by 1981, editing.gi.info says about qedx:

This is the standard Multics editor.
--
Adam Sampson <ats@offog.org> <http://offog.org/>
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

with <1105ae4$1naub$1@dont-email.me> Janis Papanagnou wrote:

On 2026-06-08 04:16, Zayd Mohammed wrote:

*SKIP* [ 5 lines 2 levels deep]

right now, i am using ed to edit this post!

*SKIP* [ 1 line 1 level deep]

Is that the reason why the formatting of your post is corrupt? (Or is
it your newsreader settings?)

(on parentheses) No. slrn doesn't post format; it will complain about technical netiquette (if configured), but otherwise just accept whatever
is '.article' or '.followup'. Sure, elaborate schemes can be
implemented (it's scriptable after all, so to speak (from experience)).
But I don't think that's what has happened.

Speculation. What is present is result of (1) type some letters in
'ed'; (2) '%p'; (3) copy-paste result to whatever slrn (that's
debatable) has picked as 'editor'; (4) post that marvel to Usenet.

Elaborate line-wrapping comes from interfering terminal -- it wraps
lines hard instead of being intelligent about it.

*CUT* [ 11 lines 2 levels deep]

And speaking of terminals. There's that long forgotten saying: "Put
the Subject of Your Message in the Subject of Your Message". Fscked up encodings? In the day and age? We all gonna die.
--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

Janis Papanagnou <janis_papanagnou+ng@hotmail.com>
writes:

'ed' is _a_ standard text editor; on Unixes.
Though a very primitive one.

It is indeed primitive, in the way a chisel is.

(I wonder why one would make ones life harder than
necessary.)

It is not harder with ed. As a user of ed,
who also used emacs and vim for over a decade,
(and many others) I don't view ed as a lesser tool
that is "behind" "modern" editors, I think ed is a
different mindset for editing, in the same vain as
vim being different from Visual Studio. If a user
of Visual Studio says in relation to learning vim:
"Why make one's life harder than necessary", the
answer would be very similar. It is harder only
because it didn't "click" for you yet.

Is that the reason why the formatting of your post
is corrupt? (Or is it your newsreader settings?)

Unlikely. I'm also writing this in ed, and
I don't think my formatting will be corrupt :)

Vim is not based on the Vi code base. But
functionally yes, mostly. And you won't gain
anything if trying to somehow relate Vim to
Ed; these are functionally completely different
things.

Vim, perhaps not. As the culture around vim
is no longer similar at all to what ed was.
People installing a 120 plugins to turn their vim
into an IDE is exactly not what ed is. But, the
original vi editors, I would say they were very
close to ed indeed. Screen editing is a big
difference of course, but with vi, you were still
meant to integrate your editor into the rest of
your UNIX environment using the vi command mode,
you don't install a plugin to wrap lines in vim,
but you pass the text to fmt from vi. With ed, it
is a very similar approach. The power of ed is
that it is open to the rest of UNIX, and through
that integration, you gain great productivity.

reply here if you use ed and would like to talk
about it, or if your nam e is ed!

I suggest to talk about editors in comp.editors
(not primarily here).

Perhaps, better yes. But if one editor is
worthy of being discussed in comp.unix.shell, it's
ed, because ed is almost completely useless if not
for the shell. I spell check in ed by calling to
a shell program !aspell %, I format the post by
doing the same !par, when I want a calendar in my
task file I !cal, etc. etc. Personally, I think
ed is the only editor that follows the UNIX
philosophy closely, it applies edits to text, and
it does so very well.

When I want to edit text, ed is my shell.


Best Regards,
Lumin Etherlight
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

Zayd Mohammed <zaydm@172.24.208.1> writes:

reply here if you use ed and would like to talk
about it, or if your nam e is ed!

Yup, ed man! I really enjoy working in
ed. It is comfy, and helps with focus a lot. I
find myself preferring it to Emacs sometimes. I
cheat a little by running it inside rlwrap,
providing some additional features like line
editing, keyboard macros, and a shortcut to clean
the screen. The power of piping text to external
utilities cannot be understated. I like using it
with `par'[1] to fold lines and align them, and I
use aspell from the command line to spellcheck. I
also like running !make and other commands to
build and run and test projects from inside ed
itself. I think it fits perfectly with the "UNIX
as IDE" mindset. Oh, and this is not a repost,
I'm actually writing this message in ed right now~
Oh, and did I tell you about the power of search
backwards when using rlwrap with ed? If I've done
something before, I don't have to remember it or
retype it, I just C-r to search my command history
and repeat the action very quickly. Good stuff.
All the docs are in ed too! !man or !info, you
have it all at your fingertips.

Sadly, I always end up in emacs anyway,
because it is a lot more than an editor to me (I'm
using GNUS to browse and post on Usenet for
example), plus, no editor I've used supports other
languages, especially RTL ones, as much as emacs
does. And I need to be able to write my RTL TeX
documents. In a way ed /does/ support RTL, if the
underlying terminal does, but no terminal I've
seen ever supported Arabic well for that. The
closest was mlterm iirc, but still, it felt off
the whole time.

So yeah, if anyone would like to talk about it~


PS. Replied here and on comp.editors, didn't realize
it was a repost from your own post 20 hours ago,
I thought it was some old circulating post. My
apologies.


Best Regards,
Lumin Etherlight
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

Zayd Mohammed <zaydm@172.24.208.1> wrote:

ed is the standard text editor.

Ed made sense when your only way to interact with a system
was through a line printer (such as a DECwriter), but when
terminals with a screen and a cursor were invented, it was
rapidly supplanted by more usable editors.

right now, i am using ed to edit this post!

And it shows ;)

Cheers,

Koen
--
Software architecture & engineering: https://www.sonologic.se/
Sci-fi: https://www.koenmartens.nl/
Retrocomputing videos: https://retroscandinavian.eu/

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On Tue, 9 Jun 2026 06:17:10 -0000 (UTC), Koen Martens wrote:

Ed made sense when your only way to interact with a system was
through a line printer (such as a DECwriter) ...

Let me suggest that TECO might be a more powerful editing system for
such an interface.

The earliest versions of Emacs were written in TECO.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Lumin Etherlight <lumin+usenet@etherlight.link> writes:

Janis Papanagnou <janis_papanagnou+ng@hotmail.com>
writes:

'ed' is _a_ standard text editor; on Unixes.
Though a very primitive one.

It is indeed primitive, in the way a chisel is.

(I wonder why one would make ones life harder than
necessary.)

It is not harder with ed. As a user of ed,
who also used emacs and vim for over a decade,
(and many others) I don't view ed as a lesser tool
that is "behind" "modern" editors, I think ed is a
different mindset for editing, in the same vain as
vim being different from Visual Studio. If a user
of Visual Studio says in relation to learning vim:
"Why make one's life harder than necessary", the
answer would be very similar. It is harder only
because it didn't "click" for you yet.

Is that the reason why the formatting of your post
is corrupt? (Or is it your newsreader settings?)

Unlikely. I'm also writing this in ed, and
I don't think my formatting will be corrupt :)

Vim is not based on the Vi code base. But
functionally yes, mostly. And you won't gain
anything if trying to somehow relate Vim to
Ed; these are functionally completely different
things.

Vim, perhaps not. As the culture around vim
is no longer similar at all to what ed was.
People installing a 120 plugins to turn their vim
into an IDE is exactly not what ed is. But, the
original vi editors, I would say they were very
close to ed indeed. Screen editing is a big
difference of course, but with vi, you were still
meant to integrate your editor into the rest of
your UNIX environment using the vi command mode,
you don't install a plugin to wrap lines in vim,
but you pass the text to fmt from vi. With ed, it
is a very similar approach. The power of ed is
that it is open to the rest of UNIX, and through
that integration, you gain great productivity.

reply here if you use ed and would like to talk
about it, or if your nam e is ed!

I suggest to talk about editors in comp.editors
(not primarily here).

Perhaps, better yes. But if one editor is
worthy of being discussed in comp.unix.shell, it's
ed, because ed is almost completely useless if not
for the shell. I spell check in ed by calling to
a shell program !aspell %, I format the post by
doing the same !par, when I want a calendar in my
task file I !cal, etc. etc. Personally, I think
ed is the only editor that follows the UNIX
philosophy closely, it applies edits to text, and
it does so very well.

When I want to edit text, ed is my shell.

I love the way your text is formatted. Lumin, how have you formatted
the text above? :-) .

I do use GNU Emacs, and I think you made a good argument for 'ed' in me.
If anyone here know how to format like the text above, but in GNU Emacs,
I would like to know how.

Cheers for Freedom,

=2D-=20
A little Consideration, a little Thought for Others, makes
all the difference. ~ Alan Alexander Milne

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJmBAEBCgBQFiEEOVeKaEm0xBhCsMmYlk/BEMQK1XUFAmon0ywbFIAAAAAABAAO bWFudTIsMi41KzEuMTEsMiwyFhxkYW4ubGlzdEBsaXNwY2x1Yi5jb20ACgkQlk/B EMQK1XUwChAAi+Fkh+oukydRGlxSTmMoj0U2AyBV8sxjCHhTJ7+YR0l2+7TZHioL 6/Rjp2WGKiLk0pL64+PEbLNJBE0ve0pGxXPpFbUy32Jxk6qxpMzG65KHGCYyRlBt uEM0IXUweblzaRDpetVPZOz86QMtLGIfy6lNOZWZYQLC+TBH4gwwK2qaSh6E+qZ/ wyuxEIXsZr16/ZIkmzzbR+xkYx3sq0+Mn2FnNHlqtJS/xLg941fnKExDskRHTqfU yzwoCgVGD5gy/WT+AVWzCtkeMTgP0XUgJMB3Go0y0JXwHOBiTcOzjxgHNmXKSOv7 8fHvxNbc31/3ciH4BZD1CDV96tOvZPdiGoGzVyXMUD9lrySg+cxNG1TkppGn4dTu vwsmVk2N4cG57vS9jRlvXdiDtrVvb9aM84Sx0kAgYidp+SfOM1hz2tw7k0oVMuZK HEhh7JUSsLA12s8dMCobeq1QVYfREcYE753pAAzn2LVv7CiR5MMPjA3wMrDIRFtF qNeFY9drpXcsZySaoslKPxKkW8Xcp8eCWSNx4/uXo7BCDJmulP/hCZiMw3Z+YXbn DukRB00rqZJ5V9jU0r/a7+1TLuTpxFFbLAnfgc0NhV2uoO5t5nLATBQtdYoSKD5z Gh3oQLBdyFdh+c8H/PDtMXRGbupgFp+g2r7GiRbV3jFpECFcNKR8PKg=
=RhGi
-----END PGP SIGNATURE-----
--=-=-=--
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

Daniel Cerqueira <dan.list@lispclub.com> writes:

Lumin Etherlight <lumin+usenet@etherlight.link> writes:

Perhaps, better yes. But if one editor is
worthy of being discussed in comp.unix.shell, it's
ed, because ed is almost completely useless if not
for the shell. I spell check in ed by calling to
a shell program !aspell %, I format the post by
doing the same !par, when I want a calendar in my
task file I !cal, etc. etc. Personally, I think
ed is the only editor that follows the UNIX
philosophy closely, it applies edits to text, and
it does so very well.

When I want to edit text, ed is my shell.

I love the way your text is formatted. Lumin, how have you formatted
the text above? :-) .

I do use GNU Emacs, and I think you made a good argument for 'ed' in me.
If anyone here know how to format like the text above, but in GNU Emacs,
I would like to know how.

Daniel wrote that he uses a program called "par" to format his texts.
You should be able to use it in emacs, too. Just mark your text and
type

C-u M-| par <ENTER>

assumed "par" is installed on your system.

The bound emacs command is `shell-command-on-region-| for further
information.

Joerg
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2026-06-08, Dan Cross <cross@spitfire.i.gajendra.net> wrote:

In article <1105ae4$1naub$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

On 2026-06-08 04:16, Zayd Mohammed wrote:

ed is the standard text editor.

'ed' is _a_ standard text editor; on Unixes. Though a very primitive
one.

Saying, "`ed` is the standard text editor" on Unix systems is an
old joke.

- Dan C.

Here's a sequel:

gopher://tilde.pink/I/~bencollver/files/dos/editor/oed/ed-joke.jpg
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2026-06-08 23:40, Keith Thompson wrote:

cross@spitfire.i.gajendra.net (Dan Cross) writes:

In article <1105ae4$1naub$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

On 2026-06-08 04:16, Zayd Mohammed wrote:

ed is the standard text editor.

'ed' is _a_ standard text editor; on Unixes. Though a very primitive
one.

Saying, "`ed` is the standard text editor" on Unix systems is an
old joke.

I recall that some versions of the ed(1) man page started with
"ed is the standard text editor".

I can't find that line on any system I have access to, or anywhere
in the history of GNU ed (which is of course not the original ed),
but a web search turns it up as a line from old man pages.
The current GNU ed man page says:

Ed is the rCOstandardrCO text editor in the sense that it is the
original editor for Unix, and thus widely available. For most
purposes, however, it is superseded by full-screen editors.

which is an implicit reference to the old wording.

So this specific meaning of "standard" predates what's now, in POSIX
era, considered standard.

But thanks for the hints to the joke; it wasn't obvious to me. And I
certainly thought that above statement, if anything, was just a part
of a more complete joke concerning editors; along the line that 'cat'
is the standard editor to create text. So 'ed' is probably overkill.

Janis

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2026-06-09 02:25, Lumin Etherlight wrote:

Janis Papanagnou <janis_papanagnou+ng@hotmail.com>
writes:

'ed' is _a_ standard text editor; on Unixes.
Though a very primitive one.

It is indeed primitive, in the way a chisel is.

(I wonder why one would make ones life harder than
necessary.)

It is not harder with ed. As a user of ed,
who also used emacs and vim for over a decade,
(and many others) I don't view ed as a lesser tool
that is "behind" "modern" editors, I think ed is a
different mindset for editing, in the same vain as
vim being different from Visual Studio. If a user
of Visual Studio says in relation to learning vim:
"Why make one's life harder than necessary", the
answer would be very similar. It is harder only
because it didn't "click" for you yet.

These comparisons ignore some facts and put others in
one bag in an undifferentiated way. I disagree in most
of what you say here.

Line oriented editing (with 'ed' or 'ex' mode of 'vi')
is different from editing larger/other entities of text.
(You may not have used those "higher-level editing" in
your time of Vi/m (or Emacs) use, I have to presume. If
you'd have done you'd probably have missed them after
your switch back to a more primitive form of editing.)

Note that I'm not saying that you couldn't do a lot of
things in line oriented mode, or in sections that are
identified by ranges (lines or patterns). There's even
things that we can do only in ex-mode of vi.[*]

And as a valid sensible comparison of 'ed' and 'vi' the
only true point is pointing out the equivalences of Vi's
'ex'-mode and 'ed'.

For me an editor is "harder" (to fulfill some task) if I
need much more key-strokes, and/or if I have to switch
to the mouse or use menus, etc., or if I just cannot do
the editing with a specific tool. And I'm only speaking
about editing here, not about any IDE-functions or other
functionality outside editing.

(Your comparisons with the MS products make no sense to
me when it's about efficient editing. - I wouldn't start
an argument and won't follow your attempt.)

Is that the reason why the formatting of your post
is corrupt? (Or is it your newsreader settings?)

Unlikely. I'm also writing this in ed, and
I don't think my formatting will be corrupt :)

To be frank, I also haven't expected that. Neither that
the 'slrn' would produce such results; quite some use
that newsreader and create clean posts. I was teasing!
But thanks for the confirmation.

(Though I'm still a bit curious what the actual reason
for his malformed post was.)

Vim is not based on the Vi code base. But
functionally yes, mostly. And you won't gain
anything if trying to somehow relate Vim to
Ed; these are functionally completely different
things.

Vim, perhaps not. As the culture around vim
is no longer similar at all to what ed was.
People installing a 120 plugins to turn their vim
into an IDE is exactly not what ed is.

I'm not sure what sick preconception you presume here.

I've certainly never installed any plugins in Vim. And
I started using Vi more than four decades ago, and I'm
using Vim almost since its beginning (without plugins).

Native Vim is still completely different to Ed (modulo
the Ex subset that has similarities with Ed, of course).

But, the
original vi editors, I would say they were very
close to ed indeed.

You can say that for 'ex' mode but certainly not for
'vi'-mode or Vim's "visual" mode, ...

Screen editing is a big
difference of course, but with vi, you were still
meant to integrate your editor into the rest of
your UNIX environment using the vi command mode,
you don't install a plugin to wrap lines in vim,
but you pass the text to fmt from vi.

...and picking a singular external filter doesn't make
the argument any better.

It's fine that the Vi concept allows to apply external
filters. (And for that specific 'fmt' example it's also
not necessary any more in Vim, of course, since it's a
builtin.)

'vi'-mode allows more than ex-mode functions and use of
external filters. And Vim makes it less necessary to use
external tools for editing purposes; but still possible.

With ed, it
is a very similar approach. The power of ed is
that it is open to the rest of UNIX, and through
that integration, you gain great productivity.

Yes, indeed. (This is a feature that 'ed' also and still
has, as 'ex'/'vi' have it.)

But editing text is generally more than being able to use
external filters.

[...]

When I want to edit text, ed is my shell.

If it's sufficient for all you want to do with an editor
it's fine.

Janis

[*] A complex example from a Vi/Vim course I once gave
:/^Start$/,$g/^# Key//Control-Key/s/Hello/Hello World/

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

Koen Martens <gmc@metro.cx> wrote:

Zayd Mohammed <zaydm@172.24.208.1> wrote:

ed is the standard text editor.

Ed made sense when your only way to interact with a system
was through a line printer (such as a DECwriter), but when
terminals with a screen and a cursor were invented, it was
rapidly supplanted by more usable editors.

There is one use for ed(1), when I boot NetBSD into single
user mode, ed(1) is the only one available without jumping
through hoops. To use it I just need to mount /tmp or / as
rw.

Not sure if that is the case with the Other BSDs.

<snip>
--
[t]csh(1) - "An elegant shell, for a more... civilized age."
- Paraphrasing Star Wars
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Joerg Mertens <joerg-mertens@t-online.de> writes:

Daniel Cerqueira <dan.list@lispclub.com> writes:

Lumin Etherlight <lumin+usenet@etherlight.link> writes:

Perhaps, better yes. But if one editor is
worthy of being discussed in comp.unix.shell, it's
ed, because ed is almost completely useless if not
for the shell. I spell check in ed by calling to
a shell program !aspell %, I format the post by
doing the same !par, when I want a calendar in my
task file I !cal, etc. etc. Personally, I think
ed is the only editor that follows the UNIX
philosophy closely, it applies edits to text, and
it does so very well.

When I want to edit text, ed is my shell.

I love the way your text is formatted. Lumin, how have you formatted
the text above? :-) .

I do use GNU Emacs, and I think you made a good argument for 'ed' in me.
If anyone here know how to format like the text above, but in GNU Emacs,
I would like to know how.

Daniel wrote that he uses a program called "par" to format his texts.
You should be able to use it in emacs, too. Just mark your text and
type

C-u M-| par <ENTER>

assumed "par" is installed on your system.

The bound emacs command is `shell-command-on-region=C2=B4 for further information.

Awesome!

I know it is not costume to use a whole article reply to say this in
Usenet, but thanks Joerg! :-))) .

Now I have to read some more of man par(1).

=2D-=20
A little Consideration, a little Thought for Others, makes
all the difference. ~ Alan Alexander Milne

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJmBAEBCgBQFiEEOVeKaEm0xBhCsMmYlk/BEMQK1XUFAmoocPIbFIAAAAAABAAO bWFudTIsMi41KzEuMTEsMiwyFhxkYW4ubGlzdEBsaXNwY2x1Yi5jb20ACgkQlk/B EMQK1XU4ug/+MNhie8LtCcVIdGDaWesSFo7voGdzFs7cJh+RAcOTERrHbJ2Q5rLA rw6AUTtiidE7bgKmYf5H6ncz4T6cgYVCfvOasZu2QK4xw2NVBodbouqYqOhhMOx/ 9ItXa/M5gnBmBzVBYoR64SKh8wNhIAeh1QKJU/JjyWrKqIS1viPgU2tcvYoYo4GX bB1e7Uj4XMnhwC52AIqBKFTTZBj9DiAsbQ8Mj0BCtt7UELEEaFTYLbn3aX51+wIc THCwtzVVHkxKsvJGphRVwbuRCtYlIWw+BuojrtRhNm5XwIxPpIlen63DRcqczAH4 tcxBpQ/fpYtKIQoNWDF4pnvTtr9FRB7AmCClbH3YFwjCn5ulBmXewqucvyB9yAiJ cnGo8vDrteQUMFuLaODS63dsyGp1Cm/DbjeA9v6PRfkdDcu+jHDE5sMRnYgREzeB t8VI1fI4awE5s0UF5Cvd8nUwNTWbwG3sJ0W0O+wNNyOw7eZN6U+bNj28RvUaVroj bwAHPCb/tbVhROEDHLKNbdHBwGUtoDgsEAd4/Snth7dRax+enw8FDFQxOyaUTivO 0lAVhAknTX3Us+iXjdPOTWGHt809P3aAQfIhGi8jrk9qW/tXfggKRNZS9e1ydeS7 ze18IxQyK92NpY/gdqEZvZBHLcZlINcMoEiMlWIZInMqrrp1pxmELBs=
=oznD
-----END PGP SIGNATURE-----
--=-=-=--
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 6/9/26 1:44 PM, John McCue wrote:

<snip>

Ed made sense when your only way to interact with a system
was through a line printer (such as a DECwriter), but when
terminals with a screen and a cursor were invented, it was
rapidly supplanted by more usable editors.

There is one use for ed(1), when I boot NetBSD into single
user mode, ed(1) is the only one available without jumping
through hoops. To use it I just need to mount /tmp or / as
rw.

Not sure if that is the case with the Other BSDs.

<snip>

I've run into that as well. Usually this works:

$ TERM=vt100 vi <some_file>

-tdc
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

Joerg Mertens <joerg-mertens@t-online.de> writes:

Daniel Cerqueira <dan.list@lispclub.com> writes:

Lumin Etherlight <lumin+usenet@etherlight.link> writes:

Perhaps, better yes. But if one editor is
worthy of being discussed in comp.unix.shell, it's
ed, because ed is almost completely useless if not
for the shell. I spell check in ed by calling to
a shell program !aspell %, I format the post by
doing the same !par, when I want a calendar in my
task file I !cal, etc. etc. Personally, I think
ed is the only editor that follows the UNIX
philosophy closely, it applies edits to text, and
it does so very well.

When I want to edit text, ed is my shell.

I love the way your text is formatted. Lumin, how have you formatted
the text above? :-) .

I do use GNU Emacs, and I think you made a good argument for 'ed' in me.
If anyone here know how to format like the text above, but in GNU Emacs,
I would like to know how.

Daniel wrote that he uses a program called "par" to format his texts.
You should be able to use it in emacs, too. Just mark your text and
type

C-u M-| par <ENTER>

assumed "par" is installed on your system.

The bound emacs command is `shell-command-on-region-| for further information.

The par program by default does not format text the way
Lumin Etherlight does. They might be using par with options.
"par -j" formats paragraphs by inserting spaces so the text is
right-justified. "par -j -w50" does the same, but with 50-character
lines. I don't see an option to insert two leading spaces on
each line.

Personally, I find Lumin's formatting distracting. For fixed-width
characters, right-justifying text by inserting blanks makes the text
more difficult to read, IMHO with no real benefit. (It tends to work
better with variable-width fonts.) Leading spaces typically denote
quoted text; adding using them on original text is unconventional,
and therefore distracting. 50 or 52 columns is much narrower than
most articles, which I also find distracting. (I use 70 or so,
typically via "fmt -w 70" or the equivalant "fmt -70".)

Lumin's formatting is clever. Clever is not always good.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
[...]

But thanks for the hints to the joke; it wasn't obvious to me. And I certainly thought that above statement, if anything, was just a part
of a more complete joke concerning editors; along the line that 'cat'
is the standard editor to create text. So 'ed' is probably overkill.

`cat`? I always use `gzip -df` to save keystrokes.

8-)}
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

ed is the standard text editor.
right now, i am using ed to edit this post!
nvim is based on vim is based on vi is based on ex is based on ed
sed and grep are also based off of ed
ed was created from qed (from which sed takes some extra commands not in ed!) ed was created by ken thompsom and dennis ritchie
https://x.com/ed1conf
https://linux.die.net/man/1/ed
https://wiki.c2.com/?EdIsTheStandardTextEditor https://en.wikipedia.org/wiki/Ed_(text_editor)
ed, man! !man ed (or i guess really !info ed)
using ed is a little like using a shell.
first show the prompt (optional) by typing P and hitting enter.
now, here are some commands than can be ran in ed:
[type a number] - go to that line number (1 is first line)
a - append text in lines after the line you were on
to stop appending, type a single period in a line by itself, and hit enter.
you can put a line number before a command to go there before running it.
. can also stand for a line number to mean the current line you are on.
[line number],[line number]d - deleter text from the first to second line number inclusive.
e - chooses a file to edit
p - print the line you are on in case you forgot
! - runs a command.
you can use ! to edit the file you are inside by using %.
e.g. !fold -s -w 67 % (this is the command i used on this post!)
you can also use it with e: e !ncal
r - like e, buts appends instead of replaces
and = - shows how many lines there are in the file.
you can put . before it to show what line number you are currently on. (.=) s/regex/regex/ - substitutes the first instances of the first regex's match with the second one. this command is used a lot in grep and sed, so it may seem
familiar.
newline by itself - go to the next line and print it (like the more command) these are just a few commands in ed. the see them all, along with more help, simply run `info ed'!
i think that's all. reply here if you use ed and would like to talk about it, or if your name is ed!

--
https://zaydiscool777.github.io/index.html
https://beacons.ai/zaydiscool777 <- list of links, not actually ai zaydiscool777@gmail.com
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2026-06-09, John McCue <jmclnx@gmail.com.invalid> wrote:

There is one use for ed(1), when I boot NetBSD into single
user mode, ed(1) is the only one available without jumping
through hoops. To use it I just need to mount /tmp or / as
rw.

Not sure if that is the case with the Other BSDs.

Same there. Very useful when you screwed up /etc/fstab.

The OpenBSD installer is a ksh script running in a very limited
environment on a ramdisk. The only editor there is ed and you can
use it to debug or directly modify the installer. Been there, done
that.

Also, ed can be used to _portably_ edit a file in-place in a script.
For instance, the Game of Trees regression tests use it for that.

"And the next time you're at a job interview where you need to
demonstrate your skills by sharing your screen, establish your
dominance early. Use ed."
https://mwl.io/static/books/ed-mastery.html
--
Christian "naddy" Weisgerber naddy@mips.inka.de
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On Tue, 9 Jun 2026 19:44:19 -0000 (UTC), John McCue wrote:

There is one use for ed(1), when I boot NetBSD into single user
mode, ed(1) is the only one available without jumping through hoops.

Why is that? Is it because NetBSD still has the legacy root-versus-usr separation of executables and libraries?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On Tue, 9 Jun 2026 23:52:03 -0000 (UTC), Christian Weisgerber wrote:

The OpenBSD installer is a ksh script running in a very limited
environment on a ramdisk. The only editor there is ed and you can
use it to debug or directly modify the installer. Been there, done
that.

Is there a BSD equivalent of this <https://www.system-rescue.org/>?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2026-06-09, Koen Martens wrote:

Zayd Mohammed <zaydm@172.24.208.1> wrote:

ed is the standard text editor.

Ed made sense when your only way to interact with a system
was through a line printer (such as a DECwriter), but when
terminals with a screen and a cursor were invented, it was
rapidly supplanted by more usable editors.

ed *is* usable, let's stop this "there are bigger/different programs
available so it has no use now" nonsense, shall we?

If we're going to put ed in that bag, sed should go there too, I
guess. After all, some such "more usable editors" can "replace" sed...

(And if you claim sed is different because it can be used in
automation... can't ed be used that way too?)
--
Nuno Silva
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

Lawrence D?Oliveiro <ldo@nz.invalid> wrote:

On Tue, 9 Jun 2026 19:44:19 -0000 (UTC), John McCue wrote:

There is one use for ed(1), when I boot NetBSD into single user
mode, ed(1) is the only one available without jumping through hoops.

Why is that? Is it because NetBSD still has the legacy root-versus-usr separation of executables and libraries?

From what I have seen, seems Linux does not have a real single
user mode. But I think that is OK for Linux.

NetBSD and the other BSDs have real single user mode where no
file systems are mounted, no daemons are started and root is
mounted RO. NetBSD boots into /bin/sh or a shell of your
choice and you work from that, no login needed. Also I think
only static executables are available for use.

I do not know what "legacy root-versus-usr" means, I would
never want a system that does not have a clear separation
between root and users.
--
[t]csh(1) - "An elegant shell, for a more... civilized age."
- Paraphrasing Star Wars
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

John McCue <jmclnx@gmail.com.invalid> writes:

Lawrence D?Oliveiro <ldo@nz.invalid> wrote:

On Tue, 9 Jun 2026 19:44:19 -0000 (UTC), John McCue wrote:

There is one use for ed(1), when I boot NetBSD into single user
mode, ed(1) is the only one available without jumping through hoops.

Why is that? Is it because NetBSD still has the legacy root-versus-usr
separation of executables and libraries?

From what I have seen, seems Linux does not have a real single
user mode. But I think that is OK for Linux.

NetBSD and the other BSDs have real single user mode where no
file systems are mounted, no daemons are started and root is
mounted RO. NetBSD boots into /bin/sh or a shell of your
choice and you work from that, no login needed. Also I think
only static executables are available for use.

I do not know what "legacy root-versus-usr" means, I would
never want a system that does not have a clear separation
between root and users.

That's not what it means.

Historically, /bin and /usr/bin were two different directories,
with /bin containing only executables that are needed during
system startup. /usr/bin can be on a separate filesystem that isn't
initially mounted. I think /usr was also where home directories were
located; for example, Dennis Ritchie's home directory was /usr/dmr.

I think the origin of that is an early PDP-11 or PDP-7 system at
Bell Labs that had limited space on its main hard drive a larger
secondary drive.

NetBSD 10.1, the latest release, retains that distinction. I have
it running in a VM, and it has 39 files in /bin and 515 in /usr/bin.
All the executables are dynamically linked, but I think they
depend on on libraries in /lib, not /usr/lib. /bin and /usr/bin
are on the same filesystem (though I think it can be configured
with /usr in its own filesystem).

Many other Unix-like systems have transitioned to making /bin a
symbolic link to /usr/bin. But remnants of the old layout still
exist; for example /usr/bin and /bin are typically both in $PATH
even if they're the same directory.

Similar things apply to /lib and /usr/bin, and to /sbin and
/usr/sbin.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

In article <110cmrj$32trj$1@dont-email.me>,
John McCue <jmclnx@gmail.com.invalid> wrote:

Lawrence D?Oliveiro <ldo@nz.invalid> wrote:

On Tue, 9 Jun 2026 19:44:19 -0000 (UTC), John McCue wrote:

There is one use for ed(1), when I boot NetBSD into single user
mode, ed(1) is the only one available without jumping through hoops.

Why is that? Is it because NetBSD still has the legacy root-versus-usr
separation of executables and libraries?

From what I have seen, seems Linux does not have a real single
user mode. But I think that is OK for Linux.

Hmm, boot with `init=/bin/sh` is probably pretty close.

NetBSD and the other BSDs have real single user mode where no
file systems are mounted, no daemons are started and root is
mounted RO. NetBSD boots into /bin/sh or a shell of your
choice and you work from that, no login needed. Also I think
only static executables are available for use.

Dynamic executables can be used, provided the shared objects
are available. "Single user mode" really just means that the
full boot sequence hasn't run and a shell got started on the
console; it doesn't change much else (all of the mounting of
filesystems and so on happens in a startup script)..

I do not know what "legacy root-versus-usr" means, I would
never want a system that does not have a clear separation
between root and users.

Lawrence is a known troll. I'm sure he's referring to the
split between `/bin` and `/usr/bin` etc. Ie, why have some
things on the root filesystem (`/bin`) and others in the `/usr`
filesystem (`/usr/bin`). There is an answer; it's historical.
`/usr` is actually the _user_ filesystem; that's where home
directories went. And there was more space on that device than
on the device that contained `/`, so `/usr/bin` was born for
binaries that were too big to fit on `/bin`.

Several systems have more or less done away with the split, now
that disk is plentiful. Linux and Solaris spring to mind;
others keep the split for organizational purposes. It doesn't
really say anything about a system, however, beyond what
aesthetics its users and maintainers subscribe to.

- Dan C.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

John McCue <jmclnx@gmail.com.invalid> writes:

[...]

I do not know what "legacy root-versus-usr" means, I would
never want a system that does not have a clear separation
between root and users.

That's not what it means.

To be clear, "root" here refers to the root filesystem, not to the
"root" user.

[SNIP]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

In article <110csrb$13aa9$2@kst.eternal-september.org>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

John McCue <jmclnx@gmail.com.invalid> writes:

Lawrence D?Oliveiro <ldo@nz.invalid> wrote:

On Tue, 9 Jun 2026 19:44:19 -0000 (UTC), John McCue wrote:

There is one use for ed(1), when I boot NetBSD into single user
mode, ed(1) is the only one available without jumping through hoops.

Why is that? Is it because NetBSD still has the legacy root-versus-usr
separation of executables and libraries?

From what I have seen, seems Linux does not have a real single
user mode. But I think that is OK for Linux.

NetBSD and the other BSDs have real single user mode where no
file systems are mounted, no daemons are started and root is
mounted RO. NetBSD boots into /bin/sh or a shell of your
choice and you work from that, no login needed. Also I think
only static executables are available for use.

I do not know what "legacy root-versus-usr" means, I would
never want a system that does not have a clear separation
between root and users.

That's not what it means.

Historically, /bin and /usr/bin were two different directories,
with /bin containing only executables that are needed during
system startup. /usr/bin can be on a separate filesystem that isn't >initially mounted. I think /usr was also where home directories were >located; for example, Dennis Ritchie's home directory was /usr/dmr.

I think the origin of that is an early PDP-11 or PDP-7 system at
Bell Labs that had limited space on its main hard drive a larger
secondary drive.

That's about right. Btw, it was the -11; the organization of
the filesystem on PDP-7 Unix was very different.

NetBSD 10.1, the latest release, retains that distinction. I have
it running in a VM, and it has 39 files in /bin and 515 in /usr/bin.
All the executables are dynamically linked, but I think they
depend on on libraries in /lib, not /usr/lib. /bin and /usr/bin
are on the same filesystem (though I think it can be configured
with /usr in its own filesystem).

Many other Unix-like systems have transitioned to making /bin a
symbolic link to /usr/bin. But remnants of the old layout still
exist; for example /usr/bin and /bin are typically both in $PATH
even if they're the same directory.

Similar things apply to /lib and /usr/bin, and to /sbin and
/usr/sbin.

Yup. I usually just make one big filesystem on most machines.
There isn't much reason to split them up anymore. Back in the
day, partition sizes were hardcoded and compiled into the
drivers for the different disk devices; you carefully chose how
you used each disk and which partitions you created filesystems
on. BSD fixed that with disklabels; many commercial Unixes
similiarly with their own proprietary versions. Now it is du
jour.

- Dan C.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

In comp.unix.shell, Dan Cross <cross@spitfire.i.gajendra.net> wrote:

Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

Historically, /bin and /usr/bin were two different directories,
with /bin containing only executables that are needed during
system startup. /usr/bin can be on a separate filesystem that isn't
initially mounted. I think /usr was also where home directories were
located; for example, Dennis Ritchie's home directory was /usr/dmr.

Yup. I usually just make one big filesystem on most machines.
There isn't much reason to split them up anymore.

I've worked with systems where /usr was a NFS filesystem. You had to get
the system booted and on the network before you got /usr/bin. Another
factor for those old space limited systems was you probably wanted
everything in /bin to be statically linked while the /usb/bin stuff
could afford to rely on dynamic libraries, again possibly existing on filesystems not mounted at boot or even not available until networking
is up.

These days you probably turn to busybox or the like when you need all statically linked utilities.

Elijah
------
busybox has vi, but a really shitty vi
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On Wed, 10 Jun 2026 22:01:23 +0000, John McCue wrote:

Lawrence D?Oliveiro <ldo@nz.invalid> wrote:

On Tue, 9 Jun 2026 19:44:19 -0000 (UTC), John McCue wrote:

There is one use for ed(1), when I boot NetBSD into single user
mode, ed(1) is the only one available without jumping through hoops.

Why is that? Is it because NetBSD still has the legacy root-versus-usr
separation of executables and libraries?

From what I have seen, seems Linux does not have a real single
user mode. But I think that is OK for Linux.

NetBSD and the other BSDs have real single user mode where no
file systems are mounted, no daemons are started and root is
mounted RO. NetBSD boots into /bin/sh or a shell of your
choice and you work from that, no login needed. Also I think
only static executables are available for use.

Oh, do you mean initlevel "S" or "s"? As in:
si:S:sysinit:/etc/rc.d/rc.S
su:1S:wait:/etc/rc.d/rc.K

20:21:14 $ head /etc/rc.d/rc.S
#!/bin/sh
#
# /etc/rc.d/rc.S: System initialization script.
#
# Mostly written by: Patrick J. Volkerding, <volkerdi@slackware.com>
#
20:22:43 $ head -12 /etc/rc.d/rc.K
#! /bin/sh
#
# rc.K This file is executed by init when it goes into runlevel
# 1, which is the administrative state. It kills all
# daemons and then puts the system into single user mode.
# Note that the file systems are kept mounted.
#
# Version: @(#)/etc/rc.d/rc.K 3.1415 Sat Jan 13 13:37:26 PST 2001
#
# Author: Miquel van Smoorenburg <miquels@drinkel.nl.mugnet.org>
# Modified by: Patrick J. Volkerding <volkerdi@slackware.com>
#

Like Slackware??

I do not know what "legacy root-versus-usr" means, I would
never want a system that does not have a clear separation
between root and users.

Agreed.

Although the OP might have meant the current (IMHO aberrant) trend
of dispensing with the /bin vs /usr/bin (etc) dichotomy.
--
Lew Pitcher
"In Skills We Trust"
Not LLM output - I'm just like this.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On Wed, 10 Jun 2026 22:01:23 -0000 (UTC), John McCue wrote:

On Wed, 10 Jun 2026 00:38:51 -0000 (UTC), Lawrence DrCOOliveiro wrote:

On Tue, 9 Jun 2026 19:44:19 -0000 (UTC), John McCue wrote:

There is one use for ed(1), when I boot NetBSD into single user
mode, ed(1) is the only one available without jumping through
hoops.

Why is that? Is it because NetBSD still has the legacy
root-versus-usr separation of executables and libraries?

From what I have seen, seems Linux does not have a real single user
mode.

There is no rCLreal single user moderCY in any *nix. The concept of single/multi-user mode is irrelevant to the kernel.

NetBSD and the other BSDs have real single user mode where no file
systems are mounted, no daemons are started and root is mounted RO.

You contradict yourself by saying rCLno file systems are mountedrCY and
then that rCLroot is mounted ROrCY. Which is it?

There must *always* be a filesystem mounted on / on every *nix OS
worthy of the name -- surely even the BSDs. On Linux, this is
initially initrd (the rCLinitial RAM diskrCY) which contains some minimal
code, scripts etc sufficient to find and mount the real root, as
specified in the parameters passed across from the boot loader.

But when switching over, then you canrCOt just unmount the existing root filesystem, because after all it is the root filesystem. So you mount
the new root in a temporary directory, and use a special system call rCLpivot_rootrCY <https://manpages.debian.org/pivot_root(2)>, to switch
their places around. Now when you unmount the directory where the new
root was previously mounted, it is actually the initrd yourCOre
unmounting.

As per the man page, pivot_root doesnrCOt just play a role at boot time,
it is also useful in the setup of filesystem namespaces for containers
etc.

NetBSD boots into /bin/sh or a shell of your choice and you work
from that, no login needed. Also I think only static executables are available for use.

On Linux, there is the option to specify the word rCLsinglerCY among the
boot parameters. This is a signal to the init process to pause the
startup of regular services and spawn a shell; if/when this
terminates, it continues with the full startup, including mounting of
non-root filesystem volumes. (Note the kernel itself assigns no
meaning to this boot parameter).

One recent time I tried this, it insisted in asking for the root
password before giving me shell access (could have been just that
distro). But another option that should bypass this is a boot
parameter setting like like rCLinit=/bin/bashrCY -- this tells the kernel
to run something other than the usual /sbin/init as PID 1. This
disables the normal userland startup process altogether.

But then, you could continue the normal startup with the command
rCLexec /sbin/initrCY. Or, of course, terminate the shell, which will
trigger a reboot.

I do not know what "legacy root-versus-usr" means, I would never
want a system that does not have a clear separation between root and
users.

Why, do you still keep user directories in /usr?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On Thu, 11 Jun 2026 00:12:16 -0000 (UTC), Eli the Bearded wrote:

Another factor for those old space limited systems was you probably
wanted everything in /bin to be statically linked ...

Surely not. Shared libraries save space, after all.

Executables in /bin were allowed to depend on libraries in /lib.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

In article <eli$2606102012@qaz.wtf>,
Eli the Bearded <*@eli.users.panix.com> wrote:

In comp.unix.shell, Dan Cross <cross@spitfire.i.gajendra.net> wrote:

Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

Historically, /bin and /usr/bin were two different directories,
with /bin containing only executables that are needed during
system startup. /usr/bin can be on a separate filesystem that isn't
initially mounted. I think /usr was also where home directories were
located; for example, Dennis Ritchie's home directory was /usr/dmr.

Yup. I usually just make one big filesystem on most machines.
There isn't much reason to split them up anymore.

I've worked with systems where /usr was a NFS filesystem.

I remember that, back in the SunOS 4 and earlier days. We
called it a "dataless" configuration: / and swap were local, but
/usr, /usr/local, and home directories came via NFS. It wasn't
a bad way to do things.

You had to get
the system booted and on the network before you got /usr/bin. Another
factor for those old space limited systems was you probably wanted
everything in /bin to be statically linked while the /usb/bin stuff
could afford to rely on dynamic libraries, again possibly existing on >filesystems not mounted at boot or even not available until networking
is up.

When Solaris 2 came along, essentially everything was
dynamically linked; statically linked binaries went into /sbin,
and my sense at the time was that 's' stood for 'static' (or
possibly 'standalone'). Nowadays, that is mostly system
utilities, whether statically linked or not, and so the meaning
has shifted again.

These days you probably turn to busybox or the like when you need all >statically linked utilities.

u-root ftw.

- Dan C.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

cross@spitfire.i.gajendra.net (Dan Cross) writes:

In article <eli$2606102012@qaz.wtf>,

[...]

When Solaris 2 came along, essentially everything was
dynamically linked; statically linked binaries went into /sbin,
and my sense at the time was that 's' stood for 'static' (or
possibly 'standalone'). Nowadays, that is mostly system
utilities, whether statically linked or not, and so the meaning
has shifted again.

My recollection is that the 's' in sbin (/sbin and/or /usr/sbin), has
always stood for "system". Typically an ordinary non-administrative
user would not have /sbin or /usr/sbin in their $PATH, but both
would be in the default $PATH for the root account.

Wikipedia (which is not a primary source) says it's "system" or
"superuser". https://en.wikipedia.org/wiki/Unix_filesystem#Conventional_directory_layout

I believe that the name "sbin" long predates Solaris 2.

[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
<snip>

Oh, do you mean initlevel "S" or "s"? As in:
si:S:sysinit:/etc/rc.d/rc.S
su:1S:wait:/etc/rc.d/rc.K

In a way, yes. When I boot Slackware single user, an extremely
rare occurrence, I can see whit I think are many kernel items
executing in background plus files systems are mounted. On
NetBSD, nothing is running in background and only / is mounted
RO. But for Linux that is not a major deal, just different.
That is why said "BSD has a real single user mode".

FWIW, I use lilo and I just type 'single' to boot single
user or I do a '/sbin/telinit 1'.

20:21:14 $ head /etc/rc.d/rc.S
#!/bin/sh
#
# /etc/rc.d/rc.S: System initialization script.
#
# Mostly written by: Patrick J. Volkerding, <volkerdi@slackware.com>

<snip>

Like Slackware??

I do not know what "legacy root-versus-usr" means, I would
never want a system that does not have a clear separation
between root and users.

Agreed.

Although the OP might have meant the current (IMHO aberrant) trend
of dispensing with the /bin vs /usr/bin (etc) dichotomy.

--
[t]csh(1) - "An elegant shell, for a more... civilized age."
- Paraphrasing Star Wars
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

John McCue <jmclnx@gmail.com.invalid> writes:

<snip>

I do not know what "legacy root-versus-usr" means, I would
never want a system that does not have a clear separation
between root and users.

That's not what it means.

Historically, /bin and /usr/bin were two different directories,

Thanks, I needed a translation :)

<snip>

NetBSD 10.1, the latest release, retains that distinction. I have
it running in a VM, and it has 39 files in /bin and 515 in /usr/bin.
All the executables are dynamically linked, but I think they
depend on on libraries in /lib, not /usr/lib. /bin and /usr/bin
are on the same filesystem (though I think it can be configured
with /usr in its own filesystem).

I checked, /bin/ed is dynamically linked and works in single
user mode. NetBSD 11 RC4 still uses the same format as 10.1

And yes, you can mount /usr in its own partition (see below).

Many other Unix-like systems have transitioned to making /bin a
symbolic link to /usr/bin. But remnants of the old layout still
exist; for example /usr/bin and /bin are typically both in $PATH
even if they're the same directory.

Similar things apply to /lib and /usr/bin, and to /sbin and
/usr/sbin.

My NetBSD system on a T430, I have cgd(4) active. The way I
set it up was /usr, /var, /tmp, /home and /u are in their own
"partition" on a cgd "slice". / is unencrypted. I still find
BSD slice vs partition confusing. YMMV :)
--
[t]csh(1) - "An elegant shell, for a more... civilized age."
- Paraphrasing Star Wars
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2026-06-11, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

I believe that the name "sbin" long predates Solaris 2.

BSD had an sbin _source_ directory since the beginning of the CSRG
repository in 1980. The history of the Makefiles shows that the
_install_ location of init, mount, dump, etc. moved from /etc to
/sbin in 1989.

https://github.com/jonathangray/csrg
--
Christian "naddy" Weisgerber naddy@mips.inka.de
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

On 2026-06-10 01:29, Keith Thompson wrote:

[...]

The par program by default does not format text the way
Lumin Etherlight does. They might be using par with options.
"par -j" formats paragraphs by inserting spaces so the text is
right-justified. "par -j -w50" does the same, but with 50-character
lines. I don't see an option to insert two leading spaces on
each line.

(I'm a bit astonished that Vim doesn't natively support that. -
Or does it, and I just don't know about it?)

It does, and I didn't know about it either. "gq" followed by a
motion command formats text, possibly using a configured external
program. ":help gq" in vim for more information. (I've been using
key mappings to invoke "fmt" since before I'd even heard of vim.)

Personally, I find Lumin's formatting distracting. For fixed-width
characters, right-justifying text by inserting blanks makes the text
more difficult to read, IMHO with no real benefit. (It tends to work
better with variable-width fonts.) Leading spaces typically denote
quoted text; adding using them on original text is unconventional,
and therefore distracting. 50 or 52 columns is much narrower than
most articles, which I also find distracting. (I use 70 or so,
typically via "fmt -w 70" or the equivalant "fmt -70".)
Lumin's formatting is clever. Clever is not always good.

I agree with most of what you say. And especially concerning the right-alignment with spurious spaces. (The indent I think is only
mildly annoying; usually you can identify the indent-level by the
number of '>'.) Narrower line-lengths (50-76) is okay for me; I
find the (widespread!) use of using no line-length limits at all
to be the much more annoying formatting habit.

Indentation is commonly used to mark text quoted from a source other
than the parent article (at least I do that). It's also sometimes
used for code samples.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On Thu, 11 Jun 2026 14:11:39 -0000 (UTC), John McCue wrote:

When I boot Slackware single user, an extremely rare occurrence, I
can see whit I think are many kernel items executing in background
plus files systems are mounted. On NetBSD, nothing is running in
background and only / is mounted RO. But for Linux that is not a
major deal, just different. That is why said "BSD has a real single
user mode".

ThatrCOs just Slackware, though.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2026-06-11, Janis Papanagnou wrote:

On 2026-06-10 12:03, Nuno Silva wrote:

On 2026-06-09, Koen Martens wrote:

Zayd Mohammed <zaydm@172.24.208.1> wrote:

ed is the standard text editor.

Ed made sense when your only way to interact with a system
was through a line printer (such as a DECwriter), but when
terminals with a screen and a cursor were invented, it was
rapidly supplanted by more usable editors.

ed *is* usable, let's stop this "there are bigger/different programs
available so it has no use now" nonsense, shall we?

If we're going to put ed in that bag, sed should go there too, I
guess. After all, some such "more usable editors" can "replace" sed...

(And if you claim sed is different because it can be used in
automation... can't ed be used that way too?)

This all reminds me the "If all I have is a hammer..." allegory.

Yes, with 'sed' or 'vi' I'm doing different things than with 'ex'
(or 'ed').

I use Emacs, sed, ed frequently. The first more than the others, but
this really is like having a set of screwdrivers and picking a somewhat appropriate one for each screw.



On a smartphone, I've also finally found a good text editor for Android,
it's quite extensible and configurable and for the first time I don't
end up wishing it had some Emacs feature every time I use it.
--
Nuno Silva
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2026-06-11 22:40, Keith Thompson wrote:

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

On 2026-06-10 01:29, Keith Thompson wrote:

[...]

The par program by default does not format text the way
Lumin Etherlight does. They might be using par with options.
"par -j" formats paragraphs by inserting spaces so the text is
right-justified. "par -j -w50" does the same, but with 50-character
lines. I don't see an option to insert two leading spaces on
each line.

(I'm a bit astonished that Vim doesn't natively support that. -
Or does it, and I just don't know about it?)

It does, and I didn't know about it either. "gq" followed by a
motion command formats text, possibly using a configured external
program. ":help gq" in vim for more information. (I've been using
key mappings to invoke "fmt" since before I'd even heard of vim.)

Oh, I obviously was unclear. - I had been talking about the
left-and-right block-alignment; the format we saw in Lumin's post.

'fmt' does *not* support that functionality. But 'par' *does*.

Both can be used from within Vi or Vim with its _external filter_
interface. But both are not *natively* supported in Vi. And 'gq'
in Vim supports *native* formatting like 'fmt', but not like 'par'.

You can also configure external commands. But my question was about
a "native" support; because I like editing functions independent
of environmental support, and I don't like plugins (which would be
another options for those who think plugins are a good idea).

Janis

[...]

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

On 2026-06-11 22:40, Keith Thompson wrote:

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

On 2026-06-10 01:29, Keith Thompson wrote:

[...]

The par program by default does not format text the way
Lumin Etherlight does. They might be using par with options.
"par -j" formats paragraphs by inserting spaces so the text is
right-justified. "par -j -w50" does the same, but with 50-character
lines. I don't see an option to insert two leading spaces on
each line.

(I'm a bit astonished that Vim doesn't natively support that. -
Or does it, and I just don't know about it?)

It does, and I didn't know about it either. "gq" followed by a
motion command formats text, possibly using a configured external
program. ":help gq" in vim for more information. (I've been using
key mappings to invoke "fmt" since before I'd even heard of vim.)

Oh, I obviously was unclear. - I had been talking about the
left-and-right block-alignment; the format we saw in Lumin's post.

'fmt' does *not* support that functionality. But 'par' *does*.

No I don't think you were unclear. I use "fmt" rather than
"par" because (a) "par" probably didn't exist when I started
using "fmt" (and I'm not sure "vim" did), and (b) I don't *want* left-and-right-justified text. I'm now aware that vim has a built-in
feature for formatting paragraphs, but as Darth Vader would say,
"The intertia is strong with this one".

Both can be used from within Vi or Vim with its _external filter_
interface. But both are not *natively* supported in Vi. And 'gq'
in Vim supports *native* formatting like 'fmt', but not like 'par'.

You can also configure external commands. But my question was about
a "native" support; because I like editing functions independent
of environmental support, and I don't like plugins (which would be
another options for those who think plugins are a good idea).

Quoting the vim documentation:
"""
JUSTIFYING TEXT *justify* *:Justify* *Justify()* *package-justify*

Vim has no built-in way of justifying text. However, there is a neat macro package that does the job. To use this package, execute the following
command: >vim

:packadd justify

Or put this line in your |vimrc|: >vim

:packadd! justify
"""
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2026-06-13 00:22, Keith Thompson wrote:

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

On 2026-06-11 22:40, Keith Thompson wrote:

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

On 2026-06-10 01:29, Keith Thompson wrote:

[...]

The par program by default does not format text the way
Lumin Etherlight does. They might be using par with options.
"par -j" formats paragraphs by inserting spaces so the text is
right-justified. "par -j -w50" does the same, but with 50-character
lines. I don't see an option to insert two leading spaces on
each line.

(I'm a bit astonished that Vim doesn't natively support that. -
Or does it, and I just don't know about it?)

It does, and I didn't know about it either. "gq" followed by a
motion command formats text, possibly using a configured external
program. ":help gq" in vim for more information. (I've been using
key mappings to invoke "fmt" since before I'd even heard of vim.)

Oh, I obviously was unclear. - I had been talking about the
left-and-right block-alignment; the format we saw in Lumin's post.

'fmt' does *not* support that functionality. But 'par' *does*.

No I don't think you were unclear. I use "fmt" rather than
"par" because (a) "par" probably didn't exist when I started
using "fmt" (and I'm not sure "vim" did), and (b) I don't *want* left-and-right-justified text. I'm now aware that vim has a built-in
feature for formatting paragraphs, but as Darth Vader would say,
"The intertia is strong with this one".

Then we were (and probably still are!) talking at cross purposes.

I had been asking for a built-in 'par' like function; there isn't
one. (And I thought you had been trying to support my request with
the hints to 'fmt' in your post. - So *I* probably misinterpreted
your post as being an answer to my question.)

I also don't like block-formatting for posts. But it's useful for
specific purposes, and since it's an common editing/presentation
task it should (as Vim's 'gq') be a Vim built-in, in my opinion.

('gq' I'm actually using with Vim already for a very long time.
It's very useful and easy to type and use.)

Both can be used from within Vi or Vim with its _external filter_
interface. But both are not *natively* supported in Vi. And 'gq'
in Vim supports *native* formatting like 'fmt', but not like 'par'.

You can also configure external commands. But my question was about
a "native" support; because I like editing functions independent
of environmental support, and I don't like plugins (which would be
another options for those who think plugins are a good idea).

Quoting the vim documentation:
"""
JUSTIFYING TEXT *justify* *:Justify* *Justify()* *package-justify*

Vim has no built-in way of justifying text.

Vim has 'gq' formatting natively; see point 3. below (:help gq).

gq{motion} Format the lines that {motion} moves over.
Formatting is done with one of three methods:
1. If 'formatexpr' is not empty the expression is
evaluated. This can differ for each buffer.
2. If 'formatprg' is not empty an external program
is used.
3. Otherwise formatting is done internally.

In my standard Vim environment, the settings of 1. and 2. are empty.
So internal (native) formatting is used.

However, there is a neat macro
package that does the job. To use this package, execute the following command: >vim

:packadd justify

Or put this line in your |vimrc|: >vim

:packadd! justify
"""

Yes, and this is plugin! - I said that I don't like to use plugins.
I use Vim *natively* with what it comes; it's extremely powerful as
it is already, and I want to avoid dependencies like external 'par'
commands or any plugins!

I've got an answer to my original "native block-formatting question"
("Or does it, and I just don't know about it?") also from the Vim
mailing list:

There is no built-in command but there is a plugin distributed
with vim. See ":help justify".

So I'm fine with my curiosity about that. And we can close the topic
(at least as far as my question goes). :-)

Janis

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Joerg Mertens <joerg-mertens@t-online.de> writes:

Daniel Cerqueira <dan.list@lispclub.com> writes:

Lumin Etherlight <lumin+usenet@etherlight.link> writes:

Perhaps, better yes. But if one editor is
worthy of being discussed in comp.unix.shell, it's
ed, because ed is almost completely useless if not
for the shell. I spell check in ed by calling to
a shell program !aspell %, I format the post by
doing the same !par, when I want a calendar in my
task file I !cal, etc. etc. Personally, I think
ed is the only editor that follows the UNIX
philosophy closely, it applies edits to text, and
it does so very well.

When I want to edit text, ed is my shell.

I love the way your text is formatted. Lumin, how have you formatted
the text above? :-) .

I do use GNU Emacs, and I think you made a good argument for 'ed' in me.
If anyone here know how to format like the text above, but in GNU Emacs,
I would like to know how.

Daniel wrote that he uses a program called "par" to format his texts.
You should be able to use it in emacs, too. Just mark your text and
type

C-u M-| par <ENTER>

assumed "par" is installed on your system.

Actually, 'par' is not giving good results, so I stopped using it (it
was recommended to me) and, by contrast, I started using C-u M-q on a
middle of a paragraph text, to do the job I was trying to achieve with
'par'.

M-q is the 'fill-paragraph' function. With a prefix (C-u before the
call) it justifies and fills the paragraph.

=2D-=20
A little Consideration, a little Thought for Others, makes
all the difference. ~ Alan Alexander Milne

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJmBAEBCgBQFiEEOVeKaEm0xBhCsMmYlk/BEMQK1XUFAmpG+nYbFIAAAAAABAAO bWFudTIsMi41KzEuMTEsMiwyFhxkYW4ubGlzdEBsaXNwY2x1Yi5jb20ACgkQlk/B EMQK1XWAQxAAjAyy9y2TjhAOvAWgXUYLa3N8gdzCx6zPEa5btPD5g0XaxQaF59BU PabCPER53dwXH2IdTX/jVszuLCuPyks3ILvz8VR2WTkb5zBa2OS7zLg4ZoV9rYmX Ft30OCg3k7qA9w4rNIskVUi74UbBRJ7SS71ukr+SxCXk8DUwwEYCG7HmOOqvMOok LusGdUZ5/T2v1u32L/Aj+6G1StVS1kygGRws2MFkFOq88fv1vzSs3079D3u9uUDC DIhYhyq108T5jYwm8uf/wTHiPBJS5j+XSaWUrylSUfl0vISCu6TCZ8HvkbsGBT5G YB6f0SVBd0hbEY1tj464DqGwm3C4TS1YXHiPWnKzQiIcT96Oy6q5An9YGHxRI23U UispZ4HrqEyLXEMVm9VuhDHYOhw2Ugy6HIPcG8ehNy+oCPZquM3kN7sGNyE/TJjc E1JlP4+9f6uWvCE5160lZgevRl3x4B1nK9wq0qzxu5hcXz6uytW1KYz4llI1vGOY hk/XthxLKHW4CTD3VUQXGQPpDDEfxw5tlUfDF3N99NkGzeei4gkucsh9j6fLJal0 CaV7Haos/5bce/k3/GaJKbsF49VgS3T6Kqjfk4um1hDG98tJ+Q6w2D1/TY5ikREO Fs3eYkaULNVWaPR0ReAUhHEG/1ITWMJnZgk9Hh/1NmrcdZk70fNGm0w=
=Gkbr
-----END PGP SIGNATURE-----
--=-=-=--
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On Fri, 03 Jul 2026 00:55:34 +0100, Daniel Cerqueira wrote:

M-q is the 'fill-paragraph' function.

And a very versatile one it is, too. It copes with indented text,
preserves quoting or comment prefixes, and also helpfully removes
redundant spaces. ;)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

Lawrence D?Oliveiro <ldo@nz.invalid> wrote:

On Fri, 03 Jul 2026 00:55:34 +0100, Daniel Cerqueira wrote:

M-q is the 'fill-paragraph' function.

I use this a lot :)

And a very versatile one it is, too. It copes with indented text,
preserves quoting or comment prefixes, and also helpfully removes
redundant spaces. ;)

A little warning about M-q. In GNU Emacs 30+, the scratch
buffer's M-q is redefined to something else. If you want
to use 'fill-paragraph' in the scratch buffer you may
need to add these to ~/.emacs:

;; Map M-q in *scratch* buffer
(add-hook 'lisp-interaction-mode-hook
(lambda ()
(local-set-key (kbd "M-q") 'fill-paragraph)))

FWIW, I tend to use 'fill-paragraph' a lot in scratch.
--
[t]csh(1) - "An elegant shell, for a more... civilized age."
- Paraphrasing Star Wars
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

Daniel Cerqueira <dan.list@lispclub.com> writes:
[...]

Actually, 'par' is not giving good results, so I stopped using it (it
was recommended to me) and, by contrast, I started using C-u M-q on a middle of a paragraph text, to do the job I was trying to achieve with 'par'.

M-q is the 'fill-paragraph' function. With a prefix (C-u before the call) it justifies and fills the paragraph.

And the result is that your paragraphs have extra spaces inserted
just to make the text both left- and right-justified.

My advice is to drop the prefix and fill the paragraphs *without* right-justifying them. Right-justified lines are fine with
variable-width fonts, but with fixed-width fonts I find them
distracting and unhelpful. (Note that you are almost the only
person who posts like this.)

I know I've mentioned this before. I'm not planning to do so again.
And thank you for left-justifying your text.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On Fri, 3 Jul 2026 01:32:46 -0000 (UTC), John McCue wrote:

A little warning about M-q. In GNU Emacs 30+, the scratch buffer's
M-q is redefined to something else.

I didnrCOt notice this (running Emacs 30.2, since thatrCOs what was in
Debian Unstable on my last upgrade), because I run with EmacsrCO entire
mode system disabled.

FWIW, I tend to use 'fill-paragraph' a lot in scratch.

So do I.

Oh, and I also added a buffer-protection mechanism, because I have a
shortcut (super-W) for closing the current buffer, and I was losing
the scratch buffer too often from this. ;)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2026-07-03, Lawrence DrCOOliveiro wrote:

On Fri, 3 Jul 2026 01:32:46 -0000 (UTC), John McCue wrote:

A little warning about M-q. In GNU Emacs 30+, the scratch buffer's
M-q is redefined to something else.

I didnrCOt notice this (running Emacs 30.2, since thatrCOs what was in
Debian Unstable on my last upgrade), because I run with EmacsrCO entire
mode system disabled.

FWIW, I tend to use 'fill-paragraph' a lot in scratch.

So do I.

Oh, and I also added a buffer-protection mechanism, because I have a
shortcut (super-W) for closing the current buffer, and I was losing
the scratch buffer too often from this. ;)

After spending way too long dealing with the consequences of *scratch*
not being backed up, I went with this:

(setq initial-buffer-choice "/home/[...]/scratch.org")

The point being that I use the initial buffer more for quick
note-keeping that ought to be transitory until saved in a more
appropriate fashion, but I kept getting bitten by bugs of the following
species - not saying it happened often enough, but still it happening
once an year or so would pose an issue:

* Drosophila Segmentationum Faltum

* Aedes Blackoutitis


Now more seriously, the point here is that, if that buffer is backed by
a file, it does get auto-saved and can be restored to at least a
somewhat recent copy in case of an improper Emacs shutdown.

If you rely on it for Elisp interaction, I suppose you could as well as
make it an Elisp file. I have the following, but I'm not sure the mode
still needs to be set after the buffer is set to open a file matching
.*\.org:

(setq initial-major-mode 'org-mode [...] )

Now I'm not sure this matters at all with a shortcut to close the buffer
- but I suppose that, if it's a buffer with a file, it may prompt you
before killing it? (It'd otherwise not protect as much as your
protection, I guess, because there'd still be a gap between the last
auto-save and it being killed?)

(Meanwhile, I set Emacs on Android the same way, so I can start typing
notes in the buffer it opens when it starts, and just do C-x C-s,
without having to open a file first.)
--
Nuno Silva
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2026-07-03 08:57, Nuno Silva wrote:

[...]

The point being that I use the initial buffer more for quick
note-keeping that ought to be transitory until saved in a more
appropriate fashion, but I kept getting bitten by bugs of the following species - not saying it happened often enough, but still it happening
once an year or so would pose an issue:

* Drosophila Segmentationum Faltum

* Aedes Blackoutitis

A vimcination with linucillin is known to help against all that.

Now more seriously, [...]

Nah!

Janis :-)

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2026-06-10 01:29, Keith Thompson wrote:

Joerg Mertens <joerg-mertens@t-online.de> writes:

Daniel Cerqueira <dan.list@lispclub.com> writes:

Lumin Etherlight <lumin+usenet@etherlight.link> writes:

Perhaps, better yes. But if one editor is
worthy of being discussed in comp.unix.shell, it's
ed, because ed is almost completely useless if not
for the shell. I spell check in ed by calling to
a shell program !aspell %, I format the post by
doing the same !par, when I want a calendar in my
task file I !cal, etc. etc. Personally, I think
ed is the only editor that follows the UNIX
philosophy closely, it applies edits to text, and
it does so very well.

When I want to edit text, ed is my shell.

I love the way your text is formatted. Lumin, how have you formatted
the text above? :-) .
[...]

Daniel wrote that he uses a program called "par" to format his texts.
[...]

The par program by default does not format text the way
Lumin Etherlight does. They might be using par with options.
"par -j" formats paragraphs by inserting spaces so the text is right-justified. "par -j -w50" does the same, but with 50-character
lines. I don't see an option to insert two leading spaces on
each line.

(I'm a bit astonished that Vim doesn't natively support that. -
Or does it, and I just don't know about it?)

Personally, I find Lumin's formatting distracting. For fixed-width characters, right-justifying text by inserting blanks makes the text
more difficult to read, IMHO with no real benefit. (It tends to work
better with variable-width fonts.) Leading spaces typically denote
quoted text; adding using them on original text is unconventional,
and therefore distracting. 50 or 52 columns is much narrower than
most articles, which I also find distracting. (I use 70 or so,
typically via "fmt -w 70" or the equivalant "fmt -70".)

Lumin's formatting is clever. Clever is not always good.

I agree with most of what you say. And especially concerning the right-alignment with spurious spaces. (The indent I think is only
mildly annoying; usually you can identify the indent-level by the
number of '>'.) Narrower line-lengths (50-76) is okay for me; I
find the (widespread!) use of using no line-length limits at all
to be the much more annoying formatting habit.

Janis

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2026-06-11 01:53, Dan Cross wrote:

[...] I usually just make one big filesystem on most machines.
There isn't much reason to split them up anymore. [...]

I have one comparably "small" disk/file-system for all the system
stuff. My user's homes are on a separate 3-disk ZFS file-system.
(Privately I've no network storage; though that might make sense.)

Janis

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2026-06-11 02:53, Lawrence DrCOOliveiro wrote:

On Wed, 10 Jun 2026 22:01:23 -0000 (UTC), John McCue wrote:

From what I have seen, seems Linux does not have a real single user
mode.

There is no rCLreal single user moderCY in any *nix. The concept of single/multi-user mode is irrelevant to the kernel.

Not sure what "real" should mean here. But it's not a question
of whether the kernel generally supports multi-user support.

We certainly had booted Unixes in single-user-mode to operate
administrative tasks, where no other users shall act on the
system. (Wikipedia also mentions that for the "Unix family".)

Janis

[...]

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2026-06-10 12:03, Nuno Silva wrote:

On 2026-06-09, Koen Martens wrote:

Zayd Mohammed <zaydm@172.24.208.1> wrote:

ed is the standard text editor.

Ed made sense when your only way to interact with a system
was through a line printer (such as a DECwriter), but when
terminals with a screen and a cursor were invented, it was
rapidly supplanted by more usable editors.

ed *is* usable, let's stop this "there are bigger/different programs available so it has no use now" nonsense, shall we?

If we're going to put ed in that bag, sed should go there too, I
guess. After all, some such "more usable editors" can "replace" sed...

(And if you claim sed is different because it can be used in
automation... can't ed be used that way too?)

This all reminds me the "If all I have is a hammer..." allegory.


Yes, with 'sed' or 'vi' I'm doing different things than with 'ex'
(or 'ed').

Janis

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

In article <110d6ks$15hpd$1@kst.eternal-september.org>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >cross@spitfire.i.gajendra.net (Dan Cross) writes:

In article <eli$2606102012@qaz.wtf>,

[...]

When Solaris 2 came along, essentially everything was
dynamically linked; statically linked binaries went into /sbin,
and my sense at the time was that 's' stood for 'static' (or
possibly 'standalone'). Nowadays, that is mostly system
utilities, whether statically linked or not, and so the meaning
has shifted again.

My recollection is that the 's' in sbin (/sbin and/or /usr/sbin), has
always stood for "system". Typically an ordinary non-administrative
user would not have /sbin or /usr/sbin in their $PATH, but both
would be in the default $PATH for the root account.

Wikipedia (which is not a primary source) says it's "system" or
"superuser". >https://en.wikipedia.org/wiki/Unix_filesystem#Conventional_directory_layout

Ugh, don't nerd-snipe me, Keith: I've got work I have to get
done today. :-)

I think wikipedia is right, though.

I can't remember when or where I first encountered /sbin, but I
see it was in Net/2 BSD, and I have it on good authority it was
in 4.3BSD-Reno. It's for things that _used_ to be in /etc.
Note that in those days, BSD distributions from UC Berkeley did
not have shared libraries; those came later. So everything was
de facto statically linked (kinda like how everyone drove a
manual transmission car and didn't really think about it until
the Jones's drove up with the first automatic on the block. Now
I can't even buy a new stick shift if I wanted; I digress).

It appears that the intent for /sbin et al was always for it to
hold system binaries that were not of interest to general users,
but necessary for the correct functioning of the system.

- Dan C.

--- Synchronet 3.22a-Linux NewsLink 1.2