tim (10/28/82)
It would be very useful if the next release of vi allowed view to read a file from the standard input if no file argument is given. It would read in the entire file, ignoring all characters except EOF (and possibly interrupt), then start up vi with readonly set on the file. The file of course would get stored in /tmp. A useful option for this would be -n, meaning just send the input to the standard output if it's less than n lines long. Berkeley, do you read? Tim Maroney unc!tim
jdd (10/28/82)
To extend Tim Maroney's suggestion, I'd like the editors (vi, Emacs, etc.) to deal with standard input and standard output in a useful Unixy fashion, so I could do: more `ls | vi -` or: emacs - | netnews -i "useful mail extensions" -n net.unix-wizards Of course, you can do these things from inside the editors (with some work) but I'd like to be able to do them from outside too. A screen editor I wrote some while ago (which I gave up in favor of Emacs) has this feature. Complications include not reading / writing standard input / output if it's a tty, not writing more than one copy to standard output (unless specifically desired), etc. Cheers, John DeTreville Bell Labs, Murray Hill
Michael.Young@CMU-CS-A@sri-unix (11/20/82)
From: Michael Wayne Young <Michael.Young@CMU-CS-A>
Date: 16 November 1982 1853-EST (Tuesday)
"don't extend vi, do it yourself with a shell script:" -- that's
sick. I cannot believe that anyone with any talent at using
a Unix system would write a shell script for something that
they (or anyone else they give it to) will use often. Parsing
arguments, handling interrupts, etc. are best done in a program,
not a shell script. I draw an analogy to the difference between
a compiler or an interpreter -- you don't run your BASIC interpreter
on anything that's gonna get used much; you don't compile things
(well, you shouldn't have to, but I usually do anyway) that you'll
just run once.
I think "vi" is large and complex, but it is clearly the place to
put the additions. How do you suspect "vi" reads in its input
file into its buffer in the first place? Would it be too much
trouble to alter the mechanism which does that to accept
standard input rather than opening a file? I think not.
Another point you bring up is the use of /tmp files. Ugh again.
What you end up doing is wasting more space in /tmp for a file
that you will throw away. In fact, I also find that people use
/tmp (and /usr/tmp) an awful lot when they can easily avoid it --
it's a matter of convenience (until you run out of space, or
other disaster strikes). I'd in fact be in favour of allowing
you to specify an "unnamed" file to be created, for just these
types of appplications; for example, rather than doing something
like:
f = creat ("/tmp/foo", 0666); /* Make my file, with name */
f2 = open ("/tmp/foo", 0); /* Get a readable fd too */
unlink ("/tmp/foo"); /* Throw away the filename */
... you'd instead do something like
f = creat_unnamed ("/tmp/foo");
[With 4.2BSD, this'd just be another mode bit, not a whole new
call -- save the flaming here.] Why the filename? Just so
the kernel doesn't make the decision where to put the file
(which filesystem); also note that no mode is necessary if you
don't want a filename to ever appear in a directory.
I may sound a bit too efficiency-oriented, but I think that keeping
in mind what resources you're using is important. Abusing "sh"
and "/tmp/" are just personal dislikes.
Then of course is the multi-pass nature of your approach: one pass
to copy to /tmp/, one to read into "vi", and if you wanted to alter
it, you'd also make another to copy from /tmp/ to standard output.
Yuch again.
Michaelpat (11/23/82)
#R:allegra:-56200:uicsovax:5500048:000:178 uicsovax!pat Nov 22 11:57:00 1982 ... I'll bet the "csh" version of the "pipe dream" version of vi will work many hours before the hacked-up vi version . Not afraid to start & end messages with ... Pat
mark.umcp-cs@UDel-Relay@sri-unix (11/24/82)
From: Mark Weiser <mark.umcp-cs@UDel-Relay> Date: 21 Nov 82 11:20:23 EST (Sun) "don't extend vi, do it yourself with a shell script:" -- that's sick. I cannot believe that anyone with any talent at using a Unix system would write a shell script for something that they (or anyone else they give it to) will use often. It depends on how often and on the cost of rewriting in C versus keeping the script. There is some code that I may never find the time to rewrite in C, because it involves a 10 process pipeline and runs once a month (but is still 200 lines of script). I can't believe anyone with any talent at using a Unix system would avoid the shell just because they plan to run the program more than once. Parsing arguments, handling interrupts, etc. are best done in a program, not a shell script. Not at all. The shells are ideal for passing arguements, much better than C for normal use. I think "vi" is large and complex, but it is clearly the place to put the additions. How do you suspect "vi" reads in its input file into its buffer in the first place? Would it be too much trouble to alter the mechanism which does that to accept standard input rather than opening a file? I think not. The problem with this approach is two fold. First, if you are the system manager then you have just introduced an extra level of maintenance for yourself as future revisions of vi are released, people migrate to your system who are used to the unextended vi, etc. Second, if multiple vi's are kept around, there is a problem with occupying unnecessary disk space for object files. (Our two rp06's run at 99% or worse all the time, so that is a serious problem here.) Then of course is the multi-pass nature of your approach: one pass to copy to /tmp/, one to read into "vi", and if you wanted to alter it, you'd also make another to copy from /tmp/ to standard output. Yuch again. Hey, multiple passes are great! Efficiency of programmer time is much more important than efficiency of machine time.
Michael.Young@CMU-CS-A@sri-unix (11/24/82)
From: Michael Wayne Young <Michael.Young@CMU-CS-A> Date: 21 November 1982 2024-EST (Sunday) I won't argue with most of your points if you think in terms of maintaining something at your site. My comments were based on the example at hand primarily (extension to vi), where I think most of them still apply. Only one site (that which distributes vi, of course) has to handle maintaining it, and it's something that they're already maintaining in one way or another anyway. I don't think you'd lose too much programmer time at Berkeley to get this in. I do think it'd be a major waste for zillions of little vi-using sites to build their own hacks to do it though. [Not to mention, it'd be nice to have a "standard" extension, maybe not for 'vi', but for 'ex' which might get used as a filter.] I also agree with the premise that "programmer time is much more important than efficiency of machine time", but that is all too often taken to extremes. No sense hitting a fly with a sledge hammer [as I claim shell scripts often do -- that was the main point of my argument]. Shell programmers often find the most obscure and wasteful ways to do things; how often do you see a well-though-out algorithm written as a shell script I will, however, grant that for once-only (and I include those once-a-month things as "once-only" as a practical matter) messes I often use shell scripts. [I love "foreach" loops, for example.] But if I'm gonna use it again and again, for my own purposes, I'll write a program. [It's not all that hard.] I somehow feel I'm in the minority on this though, so I'll try to shut up. Michael