8 ms·

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 s

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.

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.