-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Manish Jain wrote:
If you want to make a case for replacing ed(1), you're going to have
to come up with some concrete reasons for doing so, not just make a
(long and hyperbolic) statement that you don't like it.
Any Unix tool has to clearly fall either under the category of
non-interactive (grep, sed, ex) or interactive (vi, wget, sysinstall).
Oh really? Many Unix programs have traditionally had both a command
line mode of operation and an interactive mode, and that's still pretty
much still true. Usually when you run a program you put arguments on
the command line, and the program does what those arguments tell it to
do. But for many programs, if you run them with no arguments they run
in interactive mode and wait for the user to issue commands telling the
program what to do.
The case of non-interactive tools is simple : just do what you are told
on the commandline and exit. For interactive tools, at a minimum, the
application has to be show what data it is working on and what it does
with the data when the user presses a key (or a series of them). ed was
never meant to be non-interactive, and it does not fulfil the basic
requirements of being interactive. That's one reason. Secondly, how many
times does an average commandline user even think of using ed when he
needs to edit a file, even in the extreme case where there are no
alternatives ?
ed is an interactive program, and it has always been considered as such,
at least since BSD 4.2. Way back then there were three main editors,
ex, vi, and ed. If you had a nice video terminal then you used vi. But
if you were stuck using a hard copy terminal like a Decwriter, then you
used ex. And ed was the simplified (dumbed down) editor for newbies.
ed is an interactive program because the user "interacts" with it. You
give it command, it does something, you give it some more commands, it
does more stuff, etc. Interactive does not mean screen based.
Till the improvements are in place, we need the alternative of having vi
under /bin rather than /usr/bin.
Actually, it surprises me to what extent the core of the FreeBSD
community is enamoured with this idea of a micro-minimalistic base, in
which it is practically impossible to do anything except run fsck.
Matters don't stop there. Seeing the limitations of this approach, the
community churns up wierd workarounds like /rescue/vi, when all that was
needed was shift vi from /usr. You talk about the need for compliance
with old hardware and embedded systems to save a few kilos. How old is
the hardware that you have in mind ? The oldest system running FreeBSD I
know of is a 1997 Pentium with a 2 GB disk, and even that can easily
withstand the change I am suggesting. Machines older than that are
actually DEAD and don't have to be factored in. As for embedded systems,
the primary target of FreeBSD is servers, workstations and *tops. The
embedded world hasn't survived riding on FreeBSD, nor the other way
round. So from the viewpoint of the greatest good of the largest number,
over-indulging a mindset fixed around minimizing the base only leads to
degradation, not improvement. Getting to boast of a 900K / won't do any
good when people are thinking of having decent firepower (even while in
single-user mode) and its ease of use.
It's not just keeping the core system small, it's ensuring that if the
disk containing /usr fails to mount, then you still have enough of the
system to fix the problem. Admittedly this isn't as much of a concern
now, what with rescue disks and CDs with bootable live systems, but it's
still nice to have.
John L. Templer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkpDDM0ACgkQjkAlo11skePG4wCgjq4plp71Yattn34UP9YIyv4k
VagAoKDcLGVPQBxae6FABGa5hLI9w4gM
=+Ed7
-----END PGP SIGNATURE-----
