The question of moving vi to /bin

Konrad Heuer kheuer2 at gwdg.de
Thu Jun 25 12:12:24 UTC 2009


On Thu, 25 Jun 2009, 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). 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 ?
>
>> There have been some recent changes:
>> 
>> http://svn.freebsd.org/changeset/base/194628 
>> <http://svn.freebsd.org/changeset/base/194628>
>> 
>> that suggest that this problem is being addressed.
>
> 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.
>
> But I guess my words are of no use when the people who matter just won't 
> listen. So I give any hopes in this regard.

Maybe you're right, maybe not.

20 years ago, I've written and edited voluminous fortran code on a silly 
rs232 terminal using ed. So, it is possible, and one can learn basics of 
ed in less than a hour. Don't you think so?

Best regards

Konrad Heuer
GWDG, Am Fassberg, 37077 Goettingen, Germany, kheuer2 at gwdg.de



More information about the freebsd-questions mailing list