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
  • 11

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
  • 357
  • 1
  • 6
  • 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`](https://unix.stackexchange.com/q/65803/108618) 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