Red Hat Bugzilla – Bug 120
_PATH_VI is set to /usr/bin/vi instead of /bin/vi
Last modified: 2008-05-01 11:37:48 EDT
/usr/bin/vi does not exist. $ which vi /bin/vi in 5.1 /usr/bin/vi is a link to ../../bin/vim
this may affect other platforms as well
This is a glibc problem; the installed paths.h provide an incorrect location for the vi executable.
change in summary may have made record unclear original error was result of crontab -e when $EDITOR is unset yes, this may be due to difference in paths.h, but I just wanted to make sure that the original error was repeatable, and understood.
The error comes from the bad header taht glibc installs; yes, crontab will have to be rebuilt, but that does not change the fact that the bug is in glibc.
understood
*** Bug 335 has been marked as a duplicate of this bug. ***
*** Bug 120 has been marked as a duplicate of this bug. *** on a fresh install of redhat 5.2/intel I have the following packages installed on a new 5.2 box. [root@mail2 bin]# rpm -qa | egrep '(cron|vi)' crontabs-1.7-3 tetex-dvilj-0.9-6 tetex-dvips-0.9-6 tetex-xdvi-0.9-6 vim-common-5.3-3 vim-minimal-5.3-3 vixie-cron-3.0.1-26 Note: when using crontab -e I get the following error: [root@mail2 bin]# crontab -e /bin/sh: /usr/bin/vi: No such file or directory crontab: "/usr/bin/vi" exited with status 126 [root@mail2 bin]# rpm -ql vim-minimal /bin/ex /bin/rvi /bin/rview /bin/vi /bin/view [root@mail2 bin]# Note: vi has been put in /bin, and crontab expects it in /usr/bin Simon ------- Additional Comments From jturner@redhat.com 12/10/98 09:13 ------- I need more information from you about the specific packages that you installed besides the ones for cron and vi. For example, did you do a workstation install, or a custom, and if so, which packages did you select. In test lab I was unable to replicate your problem, as in fresh install there was a symbolic link from /usr/bin/vi to /bin/vi.
the fact that you have a symbolic link doesn't change the fact that paths.h specifies the wrong path. I consider the link to be a work-around for this problem. the problem has been identified as paths.h in glibc. if requested, I can produce the output of rpm -qa, however my install.log is no longer around.
Fixed in glibc 2.1 available in rawhide. Will not backport to glibc 2.0 because -PATH_VI was a static string and a number of apps will have to be recompiled for it. It is easier to just recomment a symlink for /bin/vi in /usr/bin Or a symlink is provided in the vim-enhanced package
*** Bug 120 has been marked as a duplicate of this bug. *** edquota calls /usr/bin/vi, instead of /bin/vi. There is no EDIOR variable set. ------- Additional Comments From dkl@redhat.com 12/07/98 17:21 ------- I could not replicate this on a test system. There is a symbolic link in /usr/bin/ named vi that points to the vim binary. Therefore I was not able to get it to fail on a standard 5.2 installation. ------- Additional Comments From dlt@redhat.com 12/08/98 09:16 ------- I ran edquota on two systems. If I set the environment variable, EDITOR, to /bin/vi, edquota would work. With the system as distributed, this variable is not set, and edquota fails as it assumes that /usr/bin/vi exists, which it doesn't in a default install. ------- Additional Comments From dlt@redhat.com 12/08/98 09:22 ------- jbj appears to be the owner of the quota package.
*** Bug 120 has been marked as a duplicate of this bug. *** vipw in RH5.2 is hard coded to fire up /usr/bin/vi by default. There is no /usr/bin/vi, so the command doesn't work without workarounds. vi is /bin/vi, so setting EDITOR to override the broken default is one way around the problem.
*** Bug 120 has been marked as a duplicate of this bug. *** When using "custom" installation with default packages, vim-enhanced does not get installed. vim-enhanced is needed by "crontab" command though, w/o vim-enhanced, crontab will fail with "/usr/bin/vi - command not found" error. Fix: install vim-enhanced or set EDITOR environment var correctly: "export EDITOR=/bin/vi"