this post was submitted on 31 May 2026
112 points (90.0% liked)
Technology
85059 readers
2516 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related news or articles.
- Be excellent to each other!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
- Check for duplicates before posting, duplicates may be removed
- Accounts 7 days and younger will have their posts automatically removed.
Approved Bots
founded 3 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
My favourite - and I've gotten into arguments with people about this who clearly never just tried it to see what happens - is it never executes things with the shell you think it will.
So many people assume that just because their script says
#!/bin/bashat the top that cron is going to run it in bash. The reality is without ALSO settingSHELL=/bin/bashin the crontab file, you're getting your system's lowest-common-denominator shell (ash/dash/sh/whatever other gross abomination).So much time wasted debugging. And I'm generally pretty good at avoiding shell-specific syntax, I've seen the abominations of shell scripts some people write.
The one thing I do wish systemd timers offered is cron syntax backwards compatibility, rather than just its ISO8601-style time patterns. An every-5-minutes job that used to be
*/5 * * * *is nowOnCalendar=*-*-* *:0/5:0and I'm just not sure that syntax is universally an improvement.Other than a re-arrangement of the fields, what is the big difference? Harder for awk to work with?