> IMO the biggest reason shell scripts are avoided is simply because most software developers aren’t very comfortable with the syntax (tbh it does feel archaic

> IMO the biggest reason shell scripts are avoided is simply because most software developers aren’t very comfortable with the syntax (tbh it does feel archaic in certain places) or know how unixy stuff like signals, pipes etc really work. If you have to do system level tasks though it’s probably worth the effort to understand these things. Hard disagree on that one. People aren't comfortable with the syntax because it's rather awkward and the subset of portable syntax is minuscule. The syntax itself has all sorts of variations (e.g. bash 3 vs 5 vs not-bash) and when you have to leverage external programs (e.g. sed or awk) things can get hairy quickly (especially if you're trying to support both BSD and GNU userland components). From a security POV I'd much rather use not-sh style stuff. Error handling is much more accessible and robust in higher level scripting languages. Sure you can run "set -e" and hope for the best... until you have to use something that tries to stuff meaning into the exit code like grep. Handling filenames with spaces is significantly easier once you leave the sh baggage behind. As for ls(1), are you talking about BSD or GNU ls?