Maja changed the topic of ##bash-crimes to: we bash back | club of folks preoccupied in whether they could, not whether they should | logs https://libera.irclog.whitequark.org/~h~bash-crimes
Tekk has quit [Ping timeout: 252 seconds]
f[x] has quit [Remote host closed the connection]
irth has quit [Ping timeout: 245 seconds]
<sdomi> i'm not sure how i've never seen this before
<sdomi> but i'm glad that i'm not the only one with intrusive thoughts about preprocessing bash
<isabella> it's bad and boring
<isabella> i tried several times but ultimately you can't jump in any reasonable way in the middle of a compound command
<cve> nice
<cve> Well, I've only used goto for error recovery and deeply nested if statements in C so far
<cve> and I think its totally fine for this purpose :)
<isabella> that's not very crime
cve has quit [Remote host closed the connection]
cve has joined ##bash-crimes
<misentropy> goto considered awful
<misentropy> huh, was expecting it to revolve around case switch
<misentropy> that's even worse
f[x] has joined ##bash-crimes
<sdomi> misentropy: honestly same
Tekk has joined ##bash-crimes
cve has quit [Quit: connection reset by purr]
cve has joined ##bash-crimes
irth has joined ##bash-crimes
f[x] has quit [Remote host closed the connection]
<sdomi> my fellow hackers. i need a lock that can't be raced. are my options literally either "use mkdir" or "use some non-standard utility"?
<sdomi> i would like to note that, hilariously, the first result in ddg links to a blogpost that suggests `set -o noclobber` to avoid races... and then provides a locking example which I managed to race within a few seconds
<sdomi> ... nevermind, `if mkdir lock; then (...)` is a race condition too
<JAA> Is it? I thought `mkdir` was race-free.
<sdomi> run as `while true; do (./lock_mkdir.sh & ./lock_mkdir.sh & ./lock_mkdir.sh & ./lock_mkdir.sh & ./lock_mkdir.sh & ./lock_mkdir.sh & ./lock_mkdir.sh & ./lock_mkdir.sh &; echo -e '\n---'; wait) 2>/dev/null; done`
<sdomi> there should be only one dot between every `---`. if that's the case, increase the amount of invocations
<JAA> Why should there be only one dot?
<sdomi> because all of those are launched at once, and it only should `printf ".$$"` once it locks itself
<sdomi> unless my methodology is incorrect :p
<JAA> They're launched at once, but they don't all actually run at once.
<JAA> The first process to acquire the lock might exit before some later ones even attempt to lock.
<JAA> 0.01s is a very short time.
<JAA> And launching processes is one of the more expensive things you can do.
<sdomi> hm, i suppose
<sdomi> welp, can't repro when I do increase the sleep to something higher, even if i scale up the amount of invocations accordingly. so you may be right
<sdomi> noclobber seems to exhibit similar behavior, so i think that may be safe too
<JAA> Hmm
<JAA> I'd expect a simple `open` with `O_CREAT | O_EXCL` when noclobber is active, but Bash's code actually seems racy to me.
<JAA> It first does a `stat` and later calls `open` with flags depending on the return status.
<JAA> Maybe it's safe, but not sure, and portability (of the safety) is another question. `mkdir` should map to a single syscall, so it's hard to see how that could ever not be atomic.
<sdomi> problem with `mkdir` is that it only serves as a lock, while noclobber can also communicate a PID file
<sdomi> s/file// i'm tired
<sdomi> (the only usecase I see for recovering a PID from a lockfile is periodic out-of-band checks to detect stale pidfiles that didn't get removed *for some reason*. but i suppose that with a `trap 'rm -R lock' EXIT` this would be almost never needed?)