# From Chris_G_Demetriou@ux2.sp.cs.cmu.edu Wed Aug  7 09:55:54 1996
# To: James Graham <greywolf@siva.captech.com>
# cc: explorer@flame.org, scottr@plexus.com, jonathan@dsg.stanford.edu,
#         jspath@mail.bcpl.lib.md.us, port-i386@netbsd.org
# Subject: Re: install could use some static binaries 
# Date: Wed, 07 Aug 1996 12:55:39 -0400
# From: Chris G Demetriou <Chris_G_Demetriou@ux2.sp.cs.cmu.edu>
# 
# > # Would it be useful to have disklabel call /bin/ed if /usr/bin/vi can't be
# > # run?
# > 
# > Yes.  /usr/bin/vi is a dynamically linked executable which depends upon,
# > among other things, shared libs and a working TERMCAP/terminfo entry.
# > /bin/ed is statically linked and has no such dependencies.
# 
# Aw, hell, while we're at it, why don't we change the default behaviour
# of all EDITOR/VISUAL-using programs to work something like:

Shows you what I get for not comprehending what was being said.

It sounded to me like the question was:

	"Would it *really* help things to run ed when you can't even run vi?"

To which the answer is, of course, "That's a silly way to put it.  Of course
having ed handy is an advantage over a non-working vi :-)".

Now that I re-read it, I see where Chris could make his comment.  Though,
to be honest, I have coded several programs that way (except for "cat"),
with a warning issued if it couldn't find vi, and an errexit if it couldn't
find ed.  Not that I ever intended to distribute the programs, mind you --
it was mostly an exercise in sanity, and it was a site-specific thing.

To sum up:  I _don't_ think that it should necessarily default to doing
something like that.  Disklabel blows up with "Cannot execute /usr/bin/vi"
and I'm immediately savvy to the fact that "EDITOR=/bin/ed export EDITOR"
should be my next incantation...

# 
# 	try the environment variable's contents if they exist,
# 	try vi if that fails,
# 	try ed if that fails,
# 	try cat if that fails...
# 
# 
# (hint: i'm kidding.)
# 
# 
# cgd
# 

				--*greywolf;