| Actually it succs bad time at file and stream processing (which I have done a bunch of with bash in recent years). It's only if you want to do trivially simple file and stream processing with a prototype level of robustness. It's too prone to all kind of unexpected bugs wrt.: - unusual file names - unusual stream output - error handling both for expected and unexpected errors (set -euo pipefail can help a bit) - accidental cross talking/pollution through env variables (local+declare+arrays do slightly improve this) - accidental output/stream pollution through debug messages,warning or unexpected formatting interfaces - hard to process, brittle plain text data Also: - doing the steam proceeding, traditional tools like cut,tr,sed,grep,etc. often have bad to terrible UX and also often have quirks which can cause bugs for edge cases (they what ok for the 90th, but we no longer have 80char line length limits and learned a lot about cli UX since then) I used small bash scripts all the time but the more I do the more I realize that it's technologically left behind and no longer appropriate for the current times. I frequently do consider replacing bash as my system shell with e.g. python+some library or something similar and the shell is for me still the main way to interact with my PC, I don't even have a GUI file manager! Through I need something reasonable responsive so not a compiled language. I'm also not a fan with implicit cached binaries lying around somewhere, maybe leaking disk space. Through my prompt is actually computed by a small rust program. Edit: writing from a phone, swipe like keyboards make it feasible but man I which they wouldn't mix up words that often. Edit: the reason I'm still using sh/bash/fish/zsh and similar is because when I consider switching I get overnighted in what I like to have, realize that it's to much work for me now and therefore postpone it to later. |