The question of moving vi to /bin

Manish Jain invalid.pointer at
Thu Jun 25 07:54:42 UTC 2009

John L. Templer wrote:
> 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
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla -
> iEYEARECAAYFAkpDDM0ACgkQjkAlo11skePG4wCgjq4plp71Yattn34UP9YIyv4k
> VagAoKDcLGVPQBxae6FABGa5hLI9w4gM
> =+Ed7

Hi John,

I really think you need to go through Unix's history again to get your 
facts anywhere close to reality.

Manish Jain
invalid.pointer at

Laast year I kudn't spell Software Engineer. Now I are won.

More information about the freebsd-questions mailing list