0

I tried backing up my Crontab to file using following command: crontab -l > backup/crontab. But this creates only empty file into directory backup and no output is printed to terminal. Exit code of that command is 0.

If I do crontab -l without redirection I get expected output:

/5 * * * * /path/to/script
...

Why is my command failing to write my Crontab contents to file and what should I do the make this work?

I am using Centos 7.7 and following versions of Cron packages installed:

crontabs-1.11-6.20121102git.el7.noarch
cronie-1.4.11-23.el7.x86_64
cronie-anacron-1.4.11-23.el7.x86_64

Shell I use is GNU bash, version 4.2.46.

EDIT:

[user@host ~]$ crontab -l > backup/crontab
[user@host ~]$ ll backup
total 248K
drwx------. 28 user user 4,0K 31.10. 09:30 .
drwxr-xr-x.  7 user user 4,0K  1.10. 12:58 ..
-rw-rw-r--.  1 user user 0    31.10. 09:30 crontab
...

Backup is local directory and has following Selinux policy: staff_u:object_r:user_home_t:s0.

EDIT2:

crontab -l > /tmp/crontab works and other locations were I have write access work too but when target is inside my home directory it fails. I wonder if selinux is causing this.

Madoc Comadrin
  • 218
  • 3
  • 12

1 Answers1

-3

To faithfully redirect console output, save the output as a string, using quotes to absolutely preserve the contents, like so:

echo "$(crontab -l)" > backup/crontab

or, as per comments (which I didn't think through fast enough, apologies!)

printf "%s\n" "$(crontab -l)" > backup/crontab

This prevents the redirected output from being interpreted in any way... for example, the forward slash at the beginning of your crontab example. Note that "echo -e" will interpret escape sequences - eg. chars like \n, \r, \t etc. - so use "echo" without the switch.

On most systems the simple redirect (crontab -l > filename), as you use, should be just fine.

sarlacii
  • 367
  • 3
    The way the user originally redirected the output of crontab -l to a file looks correct to me. The shell would not interpret any part of the output. With your code, however, the echo utility may well interpret the data, and, depending on how the shell is configured, do things like replacing \t with literal tabs etc. – Kusalananda Oct 31 '19 at 06:50
  • With this contents of my Crontab get correctly saved to file. On other devices simple redirection works. I wonder why on this particular computer I this is needed. – Madoc Comadrin Oct 31 '19 at 07:48
  • @Kusalananda and Madoc: Absolutely agree, I also backup using simple crontab -l > and it works just fine. Not sure why this use-case fails. Echo will only interpret "escaped" chars with -e CLI switch? (I left off -e so that "escaped" contents would not be interpreted). My assumption was that a crontab -l should not include any weird contents anyway, so echo "" should be good way to hack correct output. – sarlacii Oct 31 '19 at 07:55
  • printf would be better anyway. – Kamil Maciorowski Oct 31 '19 at 08:21
  • 1
    @sarlacii printf "%s\n" "$(crontab -l)" won't interpret anything – muru Oct 31 '19 at 09:03
  • Yes, printf won't interpret anything, which means it should be the same as crontab -l >backup/crontab. If it isn't, then the answer needs to include an explanation as to why it is not the same thing. A forward slash in the redirected data is just a forward slash (I can't think of any other issue with that particular character). – Kusalananda Oct 31 '19 at 09:12
  • 1
    Well, $() removes all trailing newline characters, printf "%s\n" adds exactly one. Empty lines at the end will disappear. This shouldn't change the logic of the file, still it's not necessarily "the same as crontab -l >backup/crontab". – Kamil Maciorowski Oct 31 '19 at 09:28
  • Since it works on other machines: could it be specific uncommon shell settings? What is different in this machine compared to others (user shell, OS, versions of commands)? – FelixJN Oct 31 '19 at 10:30
  • @Fiximan I have used the redirection several servers and desktops running Centos and Debian. This device may have different selinux settings than others, there should be no other diffrences. – Madoc Comadrin Nov 01 '19 at 13:40
  • This solved my immediate problem so I accept it as answer. Though I am still curious about root cause of this issue and would like to figure out way to make simple redirection work. – Madoc Comadrin Nov 05 '19 at 08:14