Plus, if you are running shell out of necessity on a constrained system, that doesn't mean shell deserves to be a programming language where there's actual choice.
how so? there is no python or perl or ruby etc on the target. what would have been a maintainable option other than /bin/sh ? C/C++ ?
> where there's actual choice.
again what choice? :) as I said there is no other solution than what I've given. the system literally doesn't have anything else regardless what "I think" it should support.
Typically, time spent interpreting control flow in a bash script is dwarfed by time spent in the programs called by the script.
> It is literally interpret by lines
It's just splitting lines into words to build up commands. It's not compiling C++.
> starting a whole process per if statements..
In the common pattern `if command1; then command2; fi`, if command1 is a builtin (e.g., `test` or `[`), then bash does not create a subprocess.
is this a cloud AMD64 opinion that ignores the 2 trillion devices which Gartner predicts will never run python?
I recently finished a ~600 lines ash script and the kids at work which just graduated complained that *"Y u no python?" For them it was difficult to understand because apparently I avoided cat/grep/dirname/basename/etc and used shell syntax wherever possible to avoid shelling out. (the thing I did would only run when system reaches a certain load)
Everyone forgot that the target hardware has only busybox (ash) and was massively resource constrained. My only options were to implement what I was doing as an eBPF, in C, or shell (ash). The shell script took 4 days (and was refactored/optimized several times within that period), the C (or eBPF) program would have taken ~10 days and the eBPF which is the best solution is unmaintainable once I leave the company.
from a performance perspective I take a bash script any time. Also python programs over time have a risk of eventually pulling in a dozen dependencies.