Bug 37994 - crontab -e doesn't work with vim
crontab -e doesn't work with vim
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: vixie-cron (Show other bugs)
7.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Eido Inoue
David Lawrence
:
: 41291 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-04-27 01:50 EDT by redhat
Modified: 2007-04-18 12:32 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-12-07 17:36:10 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description redhat 2001-04-27 01:50:58 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.75 [de] (X11; U; Linux 2.2.16-3 i686; Nav)


'crontab -e' doesn't recognizes changes when used with VISUAL=vim.

Reproducible: Always
Steps to Reproduce:
1.VISUAL=vim crontab -e
2.edit crontab and quit vim
3.crontab says nothing has changed
	

Actual Results:  crond isn't notified so the changes made to any crontab
aren't
recognised until next reboot (or restart of crond)
Comment 1 Daniel Roesen 2001-04-27 04:43:26 EDT
I cannot reproduce this.

[root@alexis /root]# crontab -e
no crontab for root - using an empty one
crontab: installing new crontab
[root@alexis /root]# VISUAL=vim crontab -e
crontab: installing new crontab
Comment 2 Daniel Roesen 2001-04-27 04:44:46 EDT
Changing component to vixie-cron, as "crontabs" is wrong.
Comment 3 redhat 2001-04-27 12:34:29 EDT
I still get this error on every call of 'crontab -e' (well the VISUAL is either set to 'vi' or left blank).

[root@fantasy /root]# uname -a
Linux fantasy.erik-kunze.de 2.4.3 #8 Mit Apr 25 22:32:49 CEST 2001 i686 unknown
[root@fantasy ar3]# echo $VISUAL
vi
[root@fantasy ar3]# echo $LANG
de_DE@euro
[root@fantasy ar3]# crontab -e   <- made changes
crontab: no changes made to crontab

Comment 4 redhat 2001-05-03 15:27:34 EDT
Get a strace log from http://www.philosys.de/~kunze/crontab.strace
Comment 5 John Villalovos 2001-08-30 17:27:28 EDT
Is /tmp a softlink to somewhere?  I am having the same problem and my /tmp is a 
softlink
Comment 6 redhat 2001-08-31 01:04:25 EDT
Haven't you get the supplied strace logfile? And yes, /tmp is symlink to
/var/tmp (why should one keep two temporary directories on one filesystem).
However, would you finally fix this bug!
Comment 7 adastra 2001-09-04 17:04:09 EDT
Ditto for me, on a machine with /tmp as a softlink to /var/tmp on a different
partition.  emacs & pico have no problem, vim fails exactly as described above.  
	If I :w and ^Z, I can see the intended crontab intact in /tmp, but then after
quitting, all changes are lost.
Comment 8 Mike Fleetwood 2001-11-27 17:13:42 EST
I encounter the same problem.  See my email in the LKML:
http://www.cs.helsinki.fi/linux/linux-kernel/2001-42/1460.html

To summarise when Vim 6.0z BETA (from RedHat 7.1) saves a file it results in a new file with a new inode being created, but keeping the old name.  As crontab has an open file handle on the old inode it sees no change.  I solved this by down grading to Vim 5.7 (from RedHat 7.0) which saves the text in the origional inode.

There are three possible solutions:
1) Change crontab to close the file handle and reopen the it after the editor completes, but there is a warning in crontab.c:edit_cmd() saying that this is a security risk;
2) Change Vim so that it writes back to the origional inode as it use to do.  You should check with the Vim developers (http://www.vim.org/) as to why this changed just in case; or
3) Choose a different editor.
Comment 9 Need Real Name 2001-11-27 17:39:33 EST
A workaround for Emacs users: when you're about to save the crontab file, do
        M-x make-local-variable RET backup-by-copying RET
then
        M-x set-variable RET backup-by-copying RET t RET
Now when you save the file, Emacs will keep the same inode, so cron will notice 
your changes.
Comment 10 Eido Inoue 2002-02-12 14:26:24 EST
*** Bug 41291 has been marked as a duplicate of this bug. ***

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