Bug 120

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  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  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  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  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"