Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 25 Jun 2009 13:24:35 +0530
From:      Manish Jain <invalid.pointer@gmail.com>
To:        "John L. Templer" <green_tiger@comcast.net>
Cc:        bf1783@googlemail.com, FreeBSD Mailing List <freebsd-questions@freebsd.org>
Subject:   Re: The question of moving vi to /bin
Message-ID:  <4A432D3B.5030809@gmail.com>
In-Reply-To: <4A430CDF.2010205@comcast.net>
References:  <4A430505.2020909@gmail.com> <4A430CDF.2010205@comcast.net>

next in thread | previous in thread | raw e-mail | index | archive | help
John L. Templer wrote:
> -----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-----
> 

Hi John,

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

-- 
Regards
Manish Jain
invalid.pointer@gmail.com
+91-96500-10329

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A432D3B.5030809>