This was my first thought and I suppose flock(1) could be used to recreate a lot of this. But it does come with some other quality-of-life improvements like being able to list all currently-used locks, having a lock holdable by N processes etc.
flock is indeed built-in: `flock -xn /tmp/mylock.lock -c "echo running locked command"` does mutex locking in bash. Your tool might offer better ergonomics or features beyond flock's capabilities?
I don’t know the exact threshold at which you should use a real programming language instead of a bash script. But this type of work definitely exceeds it.
While in general I'd agree, this isn't necessarily just for bash scripts. It could just wrap the execution of another program allowing higher-level logic to handle concurrency and the low-level program to do it's one-at-a-time job
Sometimes you have a cron job that takes longer than it should (but inconsistently so), and another cron job that clobbers what that cron job is doing.
Good enough for me. I created the project because I love terminal, and wanted to make something using Claude (to learn how this tool works, strictly for personal enrichment) that solves a small problem I had with some overlapping cron job management.
Why not https://man7.org/linux/man-pages/man2/flock.2.html?
Nit: Probably https://man7.org/linux/man-pages/man1/flock.1.html (shell command, not the underlying libc function)
This was my first thought and I suppose flock(1) could be used to recreate a lot of this. But it does come with some other quality-of-life improvements like being able to list all currently-used locks, having a lock holdable by N processes etc.
Because that's a syscall ;) https://man7.org/linux/man-pages/man1/flock.1.html is the command line manual.
I would say one good reason is that
is a lot easier to use and remember thanWhy
and notIt's a "for" loop.
Could you elaborate?
A for loop in a shell script may sometimes look like this:
`for ((i = 0 ; i < max ; i++ )); do echo "$i"; done`
Here this is essentially a "while" loop, meaning it will keep executing the commands as long as we don't reach `exit 1`.
(; flock -n 9 || exit 1; # ... commands executed under lock ...; )
It doesn't seem to work?
(This is bash)Flock can be used in a single line for example for cronjobs.
Flock -s file && script.
Pretty simple. (I forgot the argument, I think is -s..
just pushed a change so now it's:
waitlock myapp & #... do stuff waitlock --done myapp
flock is indeed built-in: `flock -xn /tmp/mylock.lock -c "echo running locked command"` does mutex locking in bash. Your tool might offer better ergonomics or features beyond flock's capabilities?
I don’t know the exact threshold at which you should use a real programming language instead of a bash script. But this type of work definitely exceeds it.
While in general I'd agree, this isn't necessarily just for bash scripts. It could just wrap the execution of another program allowing higher-level logic to handle concurrency and the low-level program to do it's one-at-a-time job
Sometimes you have a cron job that takes longer than it should (but inconsistently so), and another cron job that clobbers what that cron job is doing.
We already have lockfile: <https://manpages.debian.org/stable/procmail/lockfile.1.en.ht...>.
Useful project, I love all things terminal, so I also enjoyed your project.
You enjoyed the project because you love the terminal?
Good enough for me. I created the project because I love terminal, and wanted to make something using Claude (to learn how this tool works, strictly for personal enrichment) that solves a small problem I had with some overlapping cron job management.
I was saying that in a questioning tone implying that I think the account is a bot.