sjb (01/11/83)
It all depends on your interpretation of a bug. I don't consider that a bug, for the mere reason that you are NOT telling vi to REMOVE the file. You are telling it to remove every line in the file and then write out the buffer. Well, the buffer now contains no lines, so it writes out an empty file. vi did exactly what it was told to. Personally, I wouldn't want it to remove the file in that case; if I did, I would have used rm, not vi.
shp (01/12/83)
My bug report concerning vi was unclear. Many people said that vi should not delete the file if all the lines were deleted. What the bug does is NOT delete ANY lines if the following command sequence is given: vi foo :1,$d ZZ If you do: vi foo :1,$d :w :q All the lines are deleted. In both cases it is assumed that 'foo' contains something. vi should delete the lines when you tell it to !! - sam praul ...decvax!ittvax!shp
ken (01/14/83)
I have come across a similar bug using ZZ in vi. I'm not exactly sure
what sequence of events caused it, but once I was editing a file which
never existed, used the ZZ command, and nothing was ever written. I'm
not sure whether I entered vi with or without an argument, used the :f
command, or perhaps vi never even had an internal name. Ever since
then I've been superstitious and have been using :wq.
Ken Turkowski
{ucbvax,decvax}!decwrl!turtlevax!kenCHUQUI@MIT-MC (03/17/83)
From: Charles F. Von Rospach <CHUQUI @ MIT-MC> Another problem with vi is this: :e foo* returns 'Too many filenames ' even when there is only one. It looks as though vi sees the * as a meta character and returns an error without checking the expansion... chuck
chris.umcp-cs@UDel-Relay (04/03/83)
From: Chris Torek <chris.umcp-cs@UDel-Relay> From: Charles F. Von Rospach <CHUQUI@MIT-MC> Another problem with vi is this: :e foo* returns 'Too many filenames' even when there is only one. It looks as though vi sees the * as a meta character and returns an error without checking the expansion... Actually, it opens a pipe to your shell and gives it the command ``echo foo*''. The shell echos ``foobar'' (or whatever) AND a newline. Vi gets confused by the newline, I think. Look in ex_io.c for the function glob(), and its caller. I'd try to fix it but I find that the shell takes too long to start up anyway, and I'm better off just typing the whole name.
sob (04/04/83)
the problem:
type :e foo*
and get the "too many filenames" error
we found this problem only when using csh, it seems that csh gives a prompt when
started even if not connected to a tty, so that vi thought it was given
2 filenames ( the prompt and the actual name )
we changed csh to check to see if stdin is a tty and give
a prompt only if it is.
scott bradner
harvard university
...decvax!genrad!wjh12!sobsmk (04/05/83)
wjh12^sob brings up the point about getting the prompt while not in an interactive shell. Let me repeat what has been said before. Your .cshrc should look like: if ($?prompt) then ... endif so that it is only executed when in an interactive shell (when the prompt var is defined). Also, this has the benefit that all the aliasing and setting aren't done for shell scripts (where they are a waste at a minimum and trouble for strange aliasing) that don't have the -f at the top. Also, for emacs users, you shouldn't use the `tty` command in your .cshrc or .login. This is because while in emacs (and running a subshell), you aren't really connected to a tty, but rather a MPX file (in 4.1bsd of course). The tty, write, and other commands that use isatty(2) won't work. It's better to check on the TERM variable to check on terminals (although this isn't always helpful) for cases like hardwaired or full screen. Keep in mind .login is executed in the login shell after .cshrc, so the initial .cshrc doesn't have the real TERM from tset. In the login shell, you have to have extra code in .login for that. --steve