Live data from Hacker News

Show HN: Linux CLI tool to provide mutex locks for long running bash ops

github.com

1–10 of 22 posts

Show HN: Linux CLI tool to provide mutex locks for long running bash ops

#1
Been exploring claude and spec-based coding, I think it turned out fairly successful. It's just a simple unix-style tool that gives you a single command to use in bash scripts to simplify mutex or semaphore locking of execution.

Show HN: Linux CLI tool to provide mutex locks for long running bash ops
github.com

Re: Show HN: Linux CLI tool to provide mutex locks for long running bash ops

#6
post #3

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.

Re: Show HN: Linux CLI tool to provide mutex locks for long running bash ops

#7
post #3

Why not https://man7.org/linux/man-pages/man2/flock.2.html ?

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

  waitlock myapp &
  JOB_PID=$!
  # ... do exclusive work ...
  kill $JOB_PID
is a lot easier to use and remember than

  (; flock -n 9 || exit 1; # ... commands executed under lock ...; ) 9>/var/lock/mylockfile

Re: Show HN: Linux CLI tool to provide mutex locks for long running bash ops

#8

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

Re: Show HN: Linux CLI tool to provide mutex locks for long running bash ops

#9
post #7
post #3

Why not https://man7.org/linux/man-pages/man2/flock.2.html ?

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 waitlock myapp & JOB_PID=$! # ... do exclusive work ... kill $JOB_PID is a lot easier to use and remember than (; flock -n 9 || exit 1; # ... commands executed under lock ...; ) 9>/var/lock/mylockfile

Why

  (; flock -n 9
and not

  ( flock -n 9

?
Post reply on HN