No. Maybe I heard and even knew what it is, but I never needed it.
You know why?
My task scheduler supports running only one instance of the task so I don't need to reinvent the wheel every time I need something to run on schedule.
Just 'somebinary args args args', 'run only one instance' and I'm done.
> flock - manage locks from shell scripts
Well, yep. Reinventing the wheel each other time.
Thanks, I have some more important things (like browsing HN) than writing shitty shell scripts.
...
> Thanks, I have some more important things (like browsing HN) than writing shitty shell scripts.
Probably a good idea, before you dig that hole of incompetence any deeper.
We're talking about crond here, which is already running the scheduled commands via sh, it's inherently involving the shell. Welcome to *NIX.
"Hur-dur! Look at me! Me mighty UNIX wizard! Bow to me!"
> running the scheduled commands via sh, it's inherently involving the shell. Welcome to *NIX.
Thanks, while you are running shell commands I'm running systems. I'm not interested in writing shell scripts for things what were solved decades ago.
Using cron (or systemd) to ensure only 1 instance is running is a valid approach.
Erm, no - flock(1) is a UNIX tool, a component if you will. It's the exact opposite of reinventing the wheel.
Not understanding the operating system you're using is fine, but it's good to at least know what you don't know.
If I need to write a wrapper script each time I need to run a task on a timer - then it is the proverbial reinventing the wheel. It doesn't matter if you call it a tool, utility or a component. Especially if this was solved decades ago.
> Not understanding the operating system you're using is fine
Ah, another mighty UNIX wizard here.
And there's your problem - you don't realize "writing a wrapper script" is actually simpler than messing with config files.
Come on, I would repeat it again - it was solved for decades. Why do you need to do the things like it's 1976? Why do you insist everyone else should do that way too and abandon the fruits of the digital age?
It was solved decades ago: in 1976. I don't understand why you feel like it wasn't.
cron goes completely against that principle - after all, you can schedule jobs with the 'at' command, and to make a repeating task, you just make it exec 'at' again each time it is called. cron is for the lazy, no real UNIX hacker would dream of using such an extravagant single-use program. /s
You are aware that flock(1) is a thing, right? And that a defacto core tenet of UNIX is composability of disparate programs that do one thing well?