Post History
Specific answer: Use gvim -f. General answer: Use the non-forking mode of your editor, i.e. if you run it in a terminal, it should wait until the editor is closed to return back control to you. E...
Answer
#3: History hidden
Specific answer: Use `gvim -f`. General answer: Use the non-forking mode of your editor, i.e. if you run it in a terminal, it should wait until the editor is closed to return back control to you. ### Explanation Look in [crontab.c, starting at `switch (pid = fork())`](https://salsa.debian.org/debian/cron/-/blob/master/crontab.c#L393) line. Cron creates a temporary file for you to edit its contents. Then it forks. The child process [exec](https://linux.die.net/man/3/exec)'s your editor of choice. The parent process waits on the child process to terminate via [wait/waitpid](https://linux.die.net/man/3/waitpid). Now, some GUI editors (of which Gvim is an example) fork to release control of the shell back to the user. So wait/waitpid returns as soon as that happens, and Cron considers that you finalized editing the temporary file, removes it, and at the point Gvim gets to actually load it, Cron was most likely faster and the file doesn't even exist anymore (this is racy though), at which point you get "... no changes made to crontab" or "No modification made" in stderr. The exact message depends on whether your distribution patches Cron, such as Debian with [Allow-editors-with-tmpfiles.patch](https://salsa.debian.org/debian/cron/-/raw/master/debian/patches/fixes/Allow-editors-with-tmpfiles.patch). Side note 1: This is probably something worth reporting upstream or to your distribution as non-obvious behavior to be, if not fixed, documented. Side note 2: That's certainly not the last program you will encounter that expect a non-forking editor.