9 ms·

Can someone explain to me how crontabs, and cron syntax, are still so popular and one of very few options available? It's not like crontabs are written all the

Can someone explain to me how crontabs, and cron syntax, are still so popular and one of very few options available? It's not like crontabs are written all the time. They don't need to be so terse. They shouldn't require learning a language... they shouldn't require a cron.guru website. Systemd timer syntax (https://wiki.archlinux.org/index.php/Systemd/Timers#Example https://wiki.archlinux.org/index.php/Systemd/Timers#Example) is far more readable, and there's still a lot of room for improvement.

Spivak 10y ago
Because it's not nearly as bad as people describe, it's extremely powerful, it's quite clever, and there's really not even a language to learn -- it's just regex/grep for timestamps. Cron ticks every minute and checks to see if any crontab entries match the current time, if so it runs the job. But standard regular expressions aren't well suited to the types of patterns people normally try to express which is why they use their own syntax.
audleman 10y ago
Sure. Spend a focused 10 minutes to really try and understand them and you'll realize that a cron line is a perfectly concise and flexible syntax for creating scheduled time events. It even handles that crazy case where you want to run on a specific day of the week. Cron lines may seem arcane at first, but then again have you ever tried to write code that was timezone aware? Welcome to a special kind of hell. What I'm trying to say is there's complexity there and you'll be a better programmer if you embrace it. Unix programmers aren't in the habit of throwing out a working system because it's hard to grok, nor building something more complex then it needs to be. I took a look at your systemd timers link and it is a more complex syntax to create the same effect. From their own caveats section: > Complexity: to set up a timed job with systemd you create two files and run a couple systemctl commands. Compare that to adding a single line to a crontab.
- scrollaway 10y ago
  > Spend a focused 10 minutes to really try and understand them I've spent the past years doing that. I do understand cron. I also strongly dislike it. You could build a thriving city within the bounds of the room there is for improvement. > It even handles that crazy case where you want to run on a specific day of the week. So does systemd's cron. Supporting "crazy cases" doesn't mean the syntax has to suck. > Cron lines may seem arcane at first, but then again have you ever tried to write code that was timezone aware? Yes... Re systemd: It's one example; it's not perfect, I wouldn't even call it good, but it's leagues ahead of cron in terms of UX already. Bonus: usage of the ini format means it's programmatically much easier to interact with the cronjob itself.
  - koytch 10y ago
    It's ugly, simple and flexible. I can live with its ugliness (I don't change my crontab every day, after all) and simplicity and flexibility beat ini format/UX/etc. any time AFAIC.
    - berntb 10y ago
      My main problem with the cron syntax is that is error prone. I'd like it to be a bit harder to get correct syntax when you write something wrong. But a simple GUI could take care of that.
      - bpchaps 10y ago
        Something curses based would be nice - no need for a GUI ;). Cron's syntax can be hellish. For example, % is treated as a special newline character (ugh) so that commands like this don't work - and it's very difficult to troubleshoot: appstartup.sh | tee -a app.`date +%Y%m%d`.log
  - bpchaps 10y ago
    Agreed. I've been a sysadmin for about ten years now and absolutely loathe them. At the surface, they're simple to use, but it very, very quickly becomes a headache as the server count increases. That, and just about everyone who uses cron forgets to clean up their old messes or adds random scripts here and there, which makes a machine's crontab very, very messy. It makes finding a rogue cron job very, very difficult to find sometimes.
- Bromskloss 10y ago
  > It even handles that crazy case where you want to run on a specific day of the week. Does it handle the, in my opinion, not crazy case of running something every, say, 100 seconds?
  - borski 10y ago
    Sadly, no. The minimum granularity is in minutes.
    - Bromskloss 10y ago
      What about every 100 minutes?
      - bahjoite 10y ago
        */100 * * * * echo "every 100 mins"
        soneil 10y ago
        Have you tried this? Since minute only counts from 0-59, it's never divisible by 100. I have a similar problem with "every 2 days". */2 looks simple enough, but it fires on the 29th, miss 30th, fires on 31st, then fires the 1st. 3 times in 4 days isn't "every 2 days". Cron only works for periods which are evenly divisible into the calendar. "every 7 minutes" doesn't work because 60 isn't evenly divisible by 7. "every 5 hours" doesn't work (in that it'll match 8pm and midnight, which are only 4 hours apart), etc.
        gkya 10y ago
        Well in cron "every two days" is more like "every second day of a month", and "ever 5 hours" like "every fifth hour of a day".
        soneil 10y ago
        I guess that's what I was getting at. "every 100 minutes" doesn't work, because cron reads it as "every 100th minute of an hour".
- morgante 10y ago
  > concise Why is having the format be so concise and terse a virtue? They could keep the flat file approach and everything about the system identical but just make it more explicit. Cron usage would become much simpler.
smhg 10y ago
Alternatively, there is the iCalendar recurrence rule syntax [0]. It shows how complex recurrency rules can get. Cron could be considered as a good mix between complexity and brevity (readability). Shameless plug: I tried to create a format in-between both in a JS project [1]. It is based on the ISO 8601 duration format [2], but it's better to stick to iCalendar. [0] https://tools.ietf.org/html/rfc2445#section-4.3.10 https://tools.ietf.org/html/rfc2445#section-4.3.10 [1] https://github.com/smhg/date-frequency-js https://github.com/smhg/date-frequency-js [2] https://en.wikipedia.org/wiki/ISO_8601#Durations https://en.wikipedia.org/wiki/ISO_8601#Durations
tdkl 10y ago
That's funny, because IMHO they both suck and require a certain time to master them. Systemd timers are just a bit different syntax, but as I first opened the linked cron.guru site, I thought about how cool it would be if it displayed the same for systemd timers as well.
ckastner 10y ago
The crontab syntax is popular because it has been standardized by POSIX: http://pubs.opengroup.org/onlinepubs/7908799/xcu/crontab.html http://pubs.opengroup.org/onlinepubs/7908799/xcu/crontab.htm... In a sense, crontabs are the lowest common denominator for scheduling tasks on POSIX-compliant systems.
michaelt 10y ago
Introducing a new, simpler design only simplifies things if you kill the old design. Otherwise everyone needs to know both and their lives aren't any simpler. Killing off old designs is exceptionally difficult for Unix. Hell, Microsoft can barely force an upgrade on everyone and they don't have a hundred forked distros.
JdeBP 10y ago
Very few? There's a whole range of options available, from Paul Jarc's runwhen to Bruce Guenter's bcron. * http://code.dogmap.org/runwhen/ http://code.dogmap.org/runwhen/ * http://untroubled.org/bcron/ http://untroubled.org/bcron/

Spivak 10y ago

Because it's not nearly as bad as people describe, it's extremely powerful, it's quite clever, and there's really not even a language to learn -- it's just regex/grep for timestamps. Cron ticks every minute and checks to see if any crontab entries match the current time, if so it runs the job. But standard regular expressions aren't well suited to the types of patterns people normally try to express which is why they use their own syntax.

audleman 10y ago

Sure. Spend a focused 10 minutes to really try and understand them and you'll realize that a cron line is a perfectly concise and flexible syntax for creating scheduled time events. It even handles that crazy case where you want to run on a specific day of the week. Cron lines may seem arcane at first, but then again have you ever tried to write code that was timezone aware? Welcome to a special kind of hell. What I'm trying to say is there's complexity there and you'll be a better programmer if you embrace it. Unix programmers aren't in the habit of throwing out a working system because it's hard to grok, nor building something more complex then it needs to be. I took a look at your systemd timers link and it is a more complex syntax to create the same effect. From their own caveats section: > Complexity: to set up a timed job with systemd you create two files and run a couple systemctl commands. Compare that to adding a single line to a crontab.

scrollaway 10y ago
> Spend a focused 10 minutes to really try and understand them I've spent the past years doing that. I do understand cron. I also strongly dislike it. You could build a thriving city within the bounds of the room there is for improvement. > It even handles that crazy case where you want to run on a specific day of the week. So does systemd's cron. Supporting "crazy cases" doesn't mean the syntax has to suck. > Cron lines may seem arcane at first, but then again have you ever tried to write code that was timezone aware? Yes... Re systemd: It's one example; it's not perfect, I wouldn't even call it good, but it's leagues ahead of cron in terms of UX already. Bonus: usage of the ini format means it's programmatically much easier to interact with the cronjob itself.
- koytch 10y ago
  It's ugly, simple and flexible. I can live with its ugliness (I don't change my crontab every day, after all) and simplicity and flexibility beat ini format/UX/etc. any time AFAIC.
  - berntb 10y ago
    My main problem with the cron syntax is that is error prone. I'd like it to be a bit harder to get correct syntax when you write something wrong. But a simple GUI could take care of that.
    - bpchaps 10y ago
      Something curses based would be nice - no need for a GUI ;). Cron's syntax can be hellish. For example, % is treated as a special newline character (ugh) so that commands like this don't work - and it's very difficult to troubleshoot: appstartup.sh | tee -a app.`date +%Y%m%d`.log
- bpchaps 10y ago
  Agreed. I've been a sysadmin for about ten years now and absolutely loathe them. At the surface, they're simple to use, but it very, very quickly becomes a headache as the server count increases. That, and just about everyone who uses cron forgets to clean up their old messes or adds random scripts here and there, which makes a machine's crontab very, very messy. It makes finding a rogue cron job very, very difficult to find sometimes.
Bromskloss 10y ago
> It even handles that crazy case where you want to run on a specific day of the week. Does it handle the, in my opinion, not crazy case of running something every, say, 100 seconds?
- borski 10y ago
  Sadly, no. The minimum granularity is in minutes.
  - Bromskloss 10y ago
    What about every 100 minutes?
    - bahjoite 10y ago
      */100 * * * * echo "every 100 mins"
      - soneil 10y ago
        Have you tried this? Since minute only counts from 0-59, it's never divisible by 100. I have a similar problem with "every 2 days". */2 looks simple enough, but it fires on the 29th, miss 30th, fires on 31st, then fires the 1st. 3 times in 4 days isn't "every 2 days". Cron only works for periods which are evenly divisible into the calendar. "every 7 minutes" doesn't work because 60 isn't evenly divisible by 7. "every 5 hours" doesn't work (in that it'll match 8pm and midnight, which are only 4 hours apart), etc.
        gkya 10y ago
        Well in cron "every two days" is more like "every second day of a month", and "ever 5 hours" like "every fifth hour of a day".
        soneil 10y ago
        I guess that's what I was getting at. "every 100 minutes" doesn't work, because cron reads it as "every 100th minute of an hour".
morgante 10y ago
> concise Why is having the format be so concise and terse a virtue? They could keep the flat file approach and everything about the system identical but just make it more explicit. Cron usage would become much simpler.

smhg 10y ago

Alternatively, there is the iCalendar recurrence rule syntax [0]. It shows how complex recurrency rules can get. Cron could be considered as a good mix between complexity and brevity (readability). Shameless plug: I tried to create a format in-between both in a JS project [1]. It is based on the ISO 8601 duration format [2], but it's better to stick to iCalendar. [0] https://tools.ietf.org/html/rfc2445#section-4.3.10 https://tools.ietf.org/html/rfc2445#section-4.3.10 [1] https://github.com/smhg/date-frequency-js https://github.com/smhg/date-frequency-js [2] https://en.wikipedia.org/wiki/ISO_8601#Durations https://en.wikipedia.org/wiki/ISO_8601#Durations

tdkl 10y ago

That's funny, because IMHO they both suck and require a certain time to master them. Systemd timers are just a bit different syntax, but as I first opened the linked cron.guru site, I thought about how cool it would be if it displayed the same for systemd timers as well.

ckastner 10y ago

The crontab syntax is popular because it has been standardized by POSIX: http://pubs.opengroup.org/onlinepubs/7908799/xcu/crontab.html http://pubs.opengroup.org/onlinepubs/7908799/xcu/crontab.htm... In a sense, crontabs are the lowest common denominator for scheduling tasks on POSIX-compliant systems.

michaelt 10y ago

Introducing a new, simpler design only simplifies things if you kill the old design. Otherwise everyone needs to know both and their lives aren't any simpler. Killing off old designs is exceptionally difficult for Unix. Hell, Microsoft can barely force an upgrade on everyone and they don't have a hundred forked distros.

JdeBP 10y ago

Very few? There's a whole range of options available, from Paul Jarc's runwhen to Bruce Guenter's bcron. * http://code.dogmap.org/runwhen/ http://code.dogmap.org/runwhen/ * http://untroubled.org/bcron/ http://untroubled.org/bcron/