Red Hat Bugzilla – Bug 135406
/bin/vi isn't POSIX compliant
Last modified: 2007-11-30 17:07:04 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2)
Description of problem:
vim does not enter complete compatibility mode when starting up as
"vi", specifically, it does not disable multi-level undo.
I expect /bin/vi to be an implementation of vi compliant with POSIX
1003.2, which is quite clear about the behaviour of "u"
Reverse the last change made to the current buffer. If repeated,
the command shall alternate between these two states, thus is its own
vim will not have this behaviour unless cp is set.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. start /bin/vi
2. enter i whatever ESC
3. press u u
Actual Results: first whatever disappears, then I get a bell
Expected Results: whatever should disappear, then reappear.
vim makes no claims to be absolutely POSIX compliant and IMHO multi-level
undo is what 99% of our users prefer. There's always the 'redo' comand CTRL-r
if want that last changes back.
If you insist on POSIX-like undo:
Please edit /etc/vimrc or your user .vimrc and a change
or add that last line if there's no line with set nocompatible.
the bug is not about vim, it is about vi. those who want multi-level undo, can
use vim. in a POSIX system, the command
PATH=`getconf PATH` vi
MUST result in a version of the vi editor which complies with POSIX. this is
not the case in Red Hat. now, Red Hat doesn't make any claims of POSIX
compliance yet, but it is one of those things which needs to be fixed to be
btw, getconf PATH may return something other than /bin as the first element.
Solaris does this, it puts some utilities in /usr/xpg4/bin in the cases where
changing the behaviour of the utilities in /bin would break too many old scripts.
such a change to getconf and a wrapper script /usr/xpg4/bin/vi containing just
export VIMINIT=":set cp"
exec /bin/vi "$@"
would be enough to fix the POSIX incompatibility.