Re: why crypt in ed?

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Sat, 6 Oct 2018 02:06:52 GMT
    From:        Kathe <kathe%sdf.org@localhost>
    Message-ID:  <201810060206.w9626qTd012326%sdf.org@localhost>

  | 	From: Greg Troxel <gdt%lexort.com@localhost>

  | 	Often, features date from Seventh Edition, Sixth, or even earlier.  The
  | 	ed(1) man page says it appeared in First Edition; I can only say it was
  | 	there in Sixth.

-x was added in 7th edition, if you think you saw it in 6th you are either
mis-remembering, or using sources closer to 7th edition (as the names
suggest, the manuals are the definitions, the sources were in a constant
state of flux, but the commonly distributed 6th edition had no -x in ed).

  | 	The BSD way is to respect tradition, absent a compelling reason.

Aside from that (and of course, assuming ed is your editor of choice), -x is
the only way to safely edit an encrypted file.  The alternative would be to
unencrypt fiirst, then edit, then encrypt again - which leaves the plaintext
version in the filesystem (consider what happens when the drug lord is
editing his customer file, and there's a raid ... he can pull the plug on the
computer, but does not have tiime to remove the unencrypted file, the
ed /tmp copy of it, or all the blocks that contain all that evidence...)

  | isn't having a tightly built ed a compelling reason enough?

No.

  | btw, why is /bin/ed dynamically linked?

Everything in /bin is dynamically linked.   It means that they all get the
benefit of libc (etc) bug fixes.

  | wouldn't it need to be usable even under extreme conditions?

That's /rescue/ed

kre