this isnt to"bash" bash, which is one of the greatest shell languages there is... except a few better ones that i dont use.

just that when im trying to"get stuff done" i find that bash is very powerful, but a little too flexible; to the point where it feels fragile rather than robust.

i feel like im working around its design a lot, escaping *everything* so it doesnt expand macros, trying out every minute change to find out if ive missed something, like i could spend the rest of forever learning"the best way" to do anything with it.

i love pipes, though. i love $(command substitution) and sometimes i even love escaping things.

what i do about it is call bash from python, where strings and arrays feel more reliable. sometimes i do tokens and arrays with pipes and sed and awk, and sometimes i use popen and handle things with lists.

beyond python 2, this is a bit of a nightmare. with all ive tried to do to make encoding reliable for both files and filenames, its not reliable. ive read 10 or 20 tutorials on the"right way" and the"easy" way, i will never love unicode strings and bytestrings-- never. python will drop support for 2 in a few years, and perhaps a fork will happen.

if not, i may have to start using node.js instead. not what i want! but seriously, ive spent hours and hours and hours and hours on pythons shiny-new garbage, and every one of those hours was a waste.

when i run bash code it looks like this:

x ="bash code goes here" ; shell # to just run it (a curses-based editor like nano for example)

x ="bash code goes here" ; arrshell # to run it and pipe output to an array (list) named x

of course this isnt python, but it gets translated to python.

sometimes bash is simply the greatest thing. the sig at the bottom is an example of how great bash can be, until you want to make a giant script with it.

There are a lot of things that you *can do* in Bash, (and other shells, or scripting languages), but that does not necessarily mean in all cases that any particular shell or scripting language is the best or even the appropriate tool to use.

When there is too much substitution and obfuscation - to make obscure or unclear:
to obfuscate a problem with extraneous information - it may not be the right approach, unless the intent of the exercise is to"cloud" or obscure the effort.

I personally find the most helpful uses of shell scripts are to simplify the process of logging into a system and to simplify command entry and system operation. Sometimes that may mean that I write scripts to make a common operation a matter of pressing one or just a few keys. If that script itself is too complicated, however, that may suggest that the script can call a program, an interface, or another script.

Moreover, the larger a script happens to be, the less likely that it is an efficient solution. There are some scripts that are fairly large that are still quite useful; nevertheless, the larger they become, the more likely it is that a software solution built into executable code or at least script functions or routines present a more usable, maintainable and understandable alternative. That's only one opinion, and it may not be right for everyone, but this kind of thinking is generally considered to be"best practice".

Just the same, each of us is free to choose what makes the most sense to us in our own work, as long as we"own" the work.
It's when others also use the work that we are limited by specific practices in the environments we are using.

definitely in agreement.