Subject: Re: install could use some static binaries
To: None <>
From: James Graham <>
List: port-i386
Date: 08/07/1996 10:39:38
# From Wed Aug  7 09:55:54 1996
# To: James Graham <>
# cc:,,,
# Subject: Re: install could use some static binaries 
# Date: Wed, 07 Aug 1996 12:55:39 -0400
# From: Chris G Demetriou <>
# > # 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