Date: Sat, 6 Oct 2018 02:06:52 GMT
From: Kathe <ka...@sdf.org>
Message-ID: <201810060206.w9626qtd012...@sdf.org>
| From: Greg Troxel <g...@lexort.com>
| 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
