It is usually instructed to introduce new cron jobs through command lines; but I found it easier (with a better control of current cron tasks) to manually edit (in text editor) the user cron file like /var/spool/cron/crontabs/root.

Is it dangerous to edit the file in text editor?

The comments in the default file is confusing. The first line says

# DO NOT EDIT THIS FILE - edit the master and reinstall.

But the fourth line says

# Edit this file to introduce tasks to be run by cron.
  • 2
    Why not just put things under /etc/cron.d? – Zoredache Jan 6 '12 at 16:50
  • It can be a good idea; but I did not mean which file to edit, I am comparing editing file by editor or running crontab command. – Googlebot Jan 7 '12 at 3:19
  • @All I guess the only difference is the syntax checking made by crontab-e. It's only a text buffer with syntax checking. You can also change your usual editor and crontab-e would load into that. The importance on the xyntax, is because all the file would be ignored if you do a mistake. Even if you use a external tool, you should use crontab-e to read file, and send it back to crontab-e when finish. Doing so you have not to worry about syntax anymore. Better to split the files from user and the systems tasks, so you should use better /etc/cron.d for user/test tasks. – erm3nda Jun 16 '15 at 15:31

If you modify the user file under crontabs, it should work. However, there are two issues to take into consideration:

  1. If you mistyped the cron entry in the file, you will not be warned as opposed to using crontab -e command.
  2. You can not edit your user file under crontabs directly without login as root or using sudo. You will get permission denied error.


One more point to add. When you edit the file directly, you may be warned by the text editor if you opened the file twice (two users accessing the same file). However, the cron list will be overwritten when using crontab -e from two different shell sessions of the same user. This is another difference.

  • very subtle points! I never faced (knew) the second problem, as I always work as root. – Googlebot Jan 6 '12 at 14:56
  • 4
    Also, the "do not edit" in the default file is because an upgrade/reinstall may overwrite that file. – Chris S Jan 6 '12 at 14:58
  • You failed to mention that a user who edits the crontab directly loses the santax checking that crontab -e provides. – Adam F Apr 20 '15 at 21:30
  • @AdamF: This is what point 1 is talking about! – Khaled Apr 22 '15 at 6:53

If I understand correctly, you are editing the file manually with a text editor because you don't want to use crontab -e. I'll guess that's because it's using vi as the editor and you are unfamiliar with it.

You change crontab -e (and other things that need an editor) to use the more familiar nano editor by running

export EDITOR=nano


crontab -e

You can make nano the permament default editor by editing your ~/.bash_profile file to include export EDITOR=nano at the end.

To answer your question, you should not edit the file directly because it might be overwritten without you knowing it. The 4th line says what it says because it comes from the crontab that you are supposed to manually edit (it would say that as the first line).

  • Thanks for descriptive reply. I am completely familiar with crontab command vi editor; but I use gedit (not in ssh terminal), as I directly connect to server from my linux desktop. – Googlebot Jan 7 '12 at 3:18
  • I also recommend to add the export EDITOR command into your bashrc file to avoid being writting it each time you log into ssh. – erm3nda Apr 26 '15 at 9:48
export VISUAL=vi

This is the correct way to change editor for crontab.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.