3 ms·

I like combining this with a bash implementation of an event API (https://github.com/bashup/events https://github.com/bashup/events). This makes it easy/idiomat

I like combining this with a bash implementation of an event API (https://github.com/bashup/events https://github.com/bashup/events). This makes it easy/idiomatic, for example, to conditionally add cleanup as you go. Glossing over some complexity, but roughly: add_cleanup(){ event on cleanup "$@" } trap "event emit 'cleanup'" HUP EXIT start_postgres(){ add_cleanup stop_postgres # actually start pg } start_apache(){ add_cleanup stop_apache # actually start apache } I wrote a little about some other places where I've used it in https://www.t-ravis.com/post/shell/neighborly_shell_with_bashup.events/#a-quick-look-at-bashupevents https://www.t-ravis.com/post/shell/neighborly_shell_with_bas... and https://t-ravis.com/post/nix/avoid_trap_clobbering_in_nix-shell/ https://t-ravis.com/post/nix/avoid_trap_clobbering_in_nix-sh... (though I make the best use of it in my private bootstrap and backup scripts...)

e12e 3y ago
Thank you for sharing - if i understand the code, the queue is serialized into bash variable(s) (arrays)? I must admit I find the code somewhat painfully terse and hard to read. Still, interesting idea. I wonder if using a temporary SQLite/Berkeley DB/etc for queue might generalize the idea to a "Unix" event system - allowing other programs and scripts to use it for coordinating? (Like logger(1) does for logging)?
- abathur 3y ago
  Yep. Definitely something you can do manually, but the API makes it easier to reason about and coordinate across otherwise disconnected/unrelated code.
  - e12e 3y ago
    Was thinking more as a "global" queue (like how psql/libpq will go look for a socket to local postgres in "the right place") - and a binary/program "event" could "magically" store ("on") and process ("emit") events in a db file /tmp/event.<namespace><random>.sqlite3 - creating/initializing or re-using db file as needed... So keep the api, but support cross process queues, more or less.

e12e 3y ago

Thank you for sharing - if i understand the code, the queue is serialized into bash variable(s) (arrays)? I must admit I find the code somewhat painfully terse and hard to read. Still, interesting idea. I wonder if using a temporary SQLite/Berkeley DB/etc for queue might generalize the idea to a "Unix" event system - allowing other programs and scripts to use it for coordinating? (Like logger(1) does for logging)?

abathur 3y ago
Yep. Definitely something you can do manually, but the API makes it easier to reason about and coordinate across otherwise disconnected/unrelated code.
- e12e 3y ago
  Was thinking more as a "global" queue (like how psql/libpq will go look for a socket to local postgres in "the right place") - and a binary/program "event" could "magically" store ("on") and process ("emit") events in a db file /tmp/event.<namespace><random>.sqlite3 - creating/initializing or re-using db file as needed... So keep the api, but support cross process queues, more or less.