Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 10882 - unable to execute "vi" from inside "more"
unable to execute "vi" from inside "more"
Product: Red Hat Linux
Classification: Retired
Component: util-linux (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bernhard Rosenkraenzer
Depends On:
  Show dependency treegraph
Reported: 2000-04-17 19:48 EDT by radvany
Modified: 2008-05-01 11:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-04-18 17:56:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description radvany 2000-04-17 19:48:45 EDT
The component "more" was not available in the drop down list for Red Hat
Linux.  Please add it so that this report will be valid, as it does not
pertain to "less".

While using "more" to view the contents of a text file, pressing "v" is
supposed to spawn "vi" to edit the file you are viewing.  This worked until
I upgraded redhat to version 6.2 (Zoot).  Now when I attempt to vi from
inside more I will get errors such as:

vi +11 majordomo.cfexec failed
vi +11 aliasesexec failed
vi +0 Logexec failed
vi +0 autobounce.cfexec failed
vi +11 autobounceexec failed
vi +11 old.aliasesexec failed

I do not recall this funtionality being available in "less" previously, but
it does work in (Zoot).  Using "vi" directly against any of these files
also worked flawlessly.  The filenames used can be extracted by removing
the "exec" suffix in column 3.  Apparently, even the error message is
broken, by not providing a space between the filename and "exec failed"
portions of the error. (or this could be a hint of the problem itself)
Comment 1 Anonymous 2000-04-18 17:56:59 EDT
The man page on more explains that this version expects vi to live in /usr/bin
rather than just bin.  Creating a link to /bin/vi in /usr/bin or linking
/usr/bin/vim to /usr/bin/vi seems to "fix" the problem for now.
Comment 2 Bernhard Rosenkraenzer 2000-06-23 08:14:13 EDT
The right component for this bug is util-linux - try "rpm -qf `which more`".

I'm fixing it now.

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