BaSzErr - blog:2022:05:29

2022-05-29_-_bash_and_raii

anonymous@undisclosed.example.com (Anonymous) — Sun, 29 May 2022 18:36:03 +0000

2022-05-29 - bash and RAII

during both $DAY_JOB and $PET_PROJECT i often use bash. like A LOT. ;) sometimes to automate some repetitive actions, sometimes to do a quick 1-off task on loads of data… anyway – there's a lot of bash involved, typically. to make scripts react properly on errors, i typically start off with:

#!/bin/bash
set -eu -o pipefail
# actual code goes here

it's almost like a c&p sequence in my head. it's great as it allows you to catch bugs and errors early and stop the action, before any more damage gets done. the common problem there however is to cleanup stuff afterwards.

let's imagine we have some complex logic, that needs 3 temp files to operate, created at different stages of the script. sth along these lines:

#!/bin/bash
set -eu -o pipefail
tmp1=$(mktemp)
# do sth with tmp1
tmp2=$(mktemp)
# do sth with tmp1 and tmp2
tmp3=$(mktemp)
# do sth with tmp1, tmp2 and tmp3
rm -f "$tmp1" "$tmp2" "$tmp3"

all good, when script goes well. the problem begins, when sth fails in the middle (eg. after creating 2nd temp file). then we end up with not calling rm -f … part, and thus leave out garbage.

in bash there is a trap statement, that allows to call some actions on given signals… or EXIT event. so you can do this:

#!/bin/bash
set -eu -o pipefail
tmp1=$(mktemp)
tmp2=$(mktemp)
tmp3=$(mktemp)
trap "rm -f '$tmp1' '$tmp2' '$tmp3'" EXIT
# do sth with tmp1
# do sth with tmp1 and tmp2
# do sth with tmp1, tmp2 and tmp3

now all the temp files will auto-cleanup nicely¹⁾. there is just one problem with that – you can have only 1 trap per signal/event in the script. declaring new one will overwrite the previous. it is therefor all good when you can say upfront what elements do you need to “release”.

but what if you don't? what if these are runtime-defined? or names are known only any at a certain point in time? there is an excellent paradigm / pattern in C++ called RAII. while there are no “object destructors” in bash, there are “scopes”. in particular you can spawn new shell, in a given “scope”, nesting things, effectively giving you as many traps as you want. example:

#!/bin/bash
set -eu -o pipefail
(
  tmp1=$(mktemp)
  trap "rm '$tmp1'" EXIT
  # do sth with tmp1
  (
    tmp2=$(mktemp)
    trap "rm '$tmp2'" EXIT
    # do sth with tmp1 and tmp2
    (
      tmp3=$(mktemp)
      trap "rm '$tmp3'" EXIT
      # do sth with tmp1, tmp2 and tmp3
    )
  )
)

…and voila! now you can have as many “cleanup” procedures as you want, each being called once resource is “descoped”. as a free bonus, it also solves the issue of failure of initialization Nth element, before trap gets registered, like in our 2nd example.

i ten to call this pattern bash-RAII – it tend to work exceptionally well in practice.

¹⁾

ok – it won't , if creating one of the temp files would fail itself. but let's leave that 1 out for a sec.

2022-05-29_-_more_on_wifi_roaming

anonymous@undisclosed.example.com (Anonymous) — Sun, 29 May 2022 17:59:11 +0000

2022-05-29 - more on WiFi roaming

almost exactly one year ago i wrote about WiFi romaing. it workes nice ever since, but i've notice it's a bit difficult to get just the right TX power setting, to make all clients eager to switch over. the problem is that in real life there is a huge difference in how well given device receives WiFi. eg. my laptop was still able to I/O most of the packages throughout the entire house, while cell phone was loosing signal 2/3 down the way.

i was wondering how could i make the WiFi roaming a bit more “aggressive” in roaming clients? it turned out to be tricky, as it's essentially a client feature. however in OpenWRT there is a nice way of “helping” clients to make the right call – “coverage cell density”. what it (effectively) does is it does not offer lower speed rates. this in turn forces clients that are further away, to switch over, as they can no longer I/O at high speeds! so client has to switch, even though connection would still be usable at degraded speeds, normally. after enabling that option, all my clients start switching over exactly as expected, where expected.

2022-05-29_-_test_your_page_with_no_javascript

anonymous@undisclosed.example.com (Anonymous) — Sun, 29 May 2022 18:33:07 +0000

2022-05-29 - test your page with no javascript

some time ago i was contacted by a software house – the usual “come work for us” stuff you get loads of at linked-in. i do note remember details at this points, however there was sth interesting enough in there, for me to check out their homepage. when it opened, i saw a huge marketing screen, that looked like this:

so… they company has zero years of experience, no experts on board and no development whatsoever. cool.

RCA? i have javascript disabled for all pages by default (#cybersec #privacy). the above counters were animated in javascript, so in order to show anything, JS had to be enabled. when it was not… well – it looked funny, to say it lightly. ;) it's astounding how many pages silently relay on JS just being there. funny enough, it doe not seem even to be a test case for pages all too often.

not testing stuff at your own risk – you know the drill… ;)