The question of moving vi to /bin

[John L. Templer]

-----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-----