Bug 135406 - /bin/vi isn't POSIX compliant
Summary: /bin/vi isn't POSIX compliant
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: vim
Version: 3.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Karsten Hopp
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2004-10-12 15:35 UTC by Kjetil T. Homme
Modified: 2007-11-30 22:07 UTC (History)
0 users

Clone Of:
Last Closed: 2005-09-07 15:33:50 UTC

Attachments (Terms of Use)

Description Kjetil T. Homme 2004-10-12 15:35:04 UTC
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" Undo

  Synopsis: u

  Reverse the last change made to the current buffer.  If repeated,
the command shall alternate between these two states, thus is its own
inverse. [...]

vim will not have this behaviour unless cp is set.

Version-Release number of selected component (if applicable):

How reproducible:

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.

Additional info:

Comment 1 Karsten Hopp 2005-09-07 15:33:50 UTC
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 
  set nocompatible
  set compatible
or add that last line if there's no line with set nocompatible.

Comment 2 Kjetil T. Homme 2005-09-07 16:02:48 UTC
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

#! /bin/sh

export VIMINIT=":set cp"
exec /bin/vi "$@"

would be enough to fix the POSIX incompatibility.

Note You need to log in before you can comment on or make changes to this bug.