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) is far more readable, and there's still a lot of room for improvement.
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.
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.
But a simple GUI could take care of that.
appstartup.sh | tee -a app.`date +%Y%m%d`.logDoes it handle the, in my opinion, not crazy case of running something every, say, 100 seconds?
*/100 * * * * echo "every 100 mins"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.
But you probably can tweak your requirement slightly.
@100 /do/my/thing.shWatch your language!
*/1 * * * * /usr/bin/bash -c '[[ $(( $(/usr/bin/date +%s) % 6000)) -eq 0 ]] && mycommand'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.
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.
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
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.
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.