|
|
|
|
|
by opinionator1
2955 days ago
|
|
"works" More like "better the devil you know" (if you can even say that much). Bash doesn't scale. Every shop larger than 1 has been burned by bash gotchas. Use a real scripting language and shell out to the commands and builtins when necessary. At my shop bash is strictly disallowed in production environments and we're all better off for it. |
|
Thanks mate, I had a good laugh.
I wouldn't expect bash to scale anyway. That's not what it's meant for. It's meant for system administration task automation.
On a more serious note ...
In many occasions, the performance you get depends on how you tackle the problem you have, though. Even using bash and the tools from the unix toolbox, sometimes you can gain significant improvements on how you manage your data.
Anecdotal: I cannot remember the details, but I remember that rearranging the order of sorting and searching and removing duplicates (sort, sort -u, grep, uniq mainly) I saw a significant speedup.
Anecdotal (2): I cut the execution time of a night-running job from hours to minutes (tens of minutes, to be honest - but still less than an hour) just by slicing the size of a problem into smaller parts and by handling each slice in parallel (the machine had 48 cpus, but the problem was being solved "sequentially" on one cpu alone). I wrote some 30-50 lines of python, just to implement parallelism control: the rest of the problem was still handled with bash script. Partial results were reassembled at the end. Bash has coprocesses, so I might have handled that in bash as well, but python was more handy at the time (meh, i just wanted to optimize that problem).
What I am trying to say is that sometimes the "scaling" you get is justified by the size of the problem, sometimes it's not.