Just because you seem to be unfamiliar with bash doesn’t mean it’s unreadable. Almost any language will look cryptic if you don’t know it. That function is mostly just parameter expansion and very common in most bash scripts. I bet if you read the manual you would easily be able to figure it out. You just have to learn the language.
I'm with jmnicolas on this. I've been using bash on and off for years now (approaching decades). I still get it very wrong almost always. It's the only language where this is a persistent problem for me.
Just yesterday I was struck by the difference between if [[ ]]; and if [ ];
I didn't even bother grokking the difference in the end. I simply found something that worked and moved on with my day.
Single square bracket conditionals [] are the "older" (POSIX) version but do not have certain features that we would like to use in our shell scripts. Bash uses double square brackets to extend the functionality.
This is my understanding. Possibly not 100% correct but essentially correct enough for me to understand the reason/rationale for the difference.
You got it! `test` is a shell builtin. `[` is basically syntactic sugar, and is a synonym for `test` with the additional requirement that the last argument must be a closing bracket `]`. `[[` is a shell keyword with more features.
I'm in no way defending bash as a language. There are lots of gotchas and weird constructs. I avoid bash too. It's just that trim function isn't that cryptic or "unreadable" if you know the syntax.
I think the point is that it takes a lot longer pick the syntax up compared to some if/then/for/loop version of trim even if that would be way more verbose.
Yes, but I think that's antithetical to what languages like bash and perl are trying to do. Someone well versed in the language can do some pretty complex operations in a few keystrokes.
which gets back to the original point that these languages have chosen to be more powerful over being more immediately readable. you have to know many more features of the language to understand what is going on compared to colloquially used constructs like if/then or for loops. If you understand english you are a lot closer to understanding the latter rather than the former, more domain specific syntax.
I don't agree at all. I don't find it less "readable". You just have to be used to it. If you understand English, German isn't that hard of a language to learn. Japanese would probably be a little bit harder to pick up though. Doesn't mean Japanese is unreadable
I mean, I would say it is. Why are there quotes around the variable? What happens when I remove the quotes?
The quotes don't function like the parens. If this were a two argument function, you wouldn't put one pair of quotes around the whole thing. They're clearly transforming the variable somehow, but I'm not sure how and/or why they're necessary.
Sure, but bash only has certain language constructs. This implementation is using parameter expansion and some other built ins. It's definitely more complex than yours, but that's what bash has to offer.
I highly recommend running shellcheck on all of your bash code. It is what finally taught me the practical difference between [[ and [. There are some tests that will always pass in [, for example, but work properly in [[; one project never realized.
My (personal) better recommendation is to avoid bash scripts whenever possible ;)
I generally tell people that, once a script is longer than ~100 lines and/or you start adding functions, you're probably better off with something like Python.
I know that's not a popular opinion with shell enthusiasts, but it's saved me so much frustration both in writing new scripts and coming back to them later for refactoring.
> I generally tell people that, once a script is longer than ~100 lines and/or you start adding functions, you're probably better off with something like Python.
Agreed. My threshold is usually "when you want to start using arrays or dictionaries". I find bash best for file manipulation and running programs in other languages
Bash is a typical Unix tool, and Unix follows the KISS principle. Hence, also Bash scripts should be KISS.
If you need >100 lines of code your code is too complex in the script world, and you should split it into several scripts where each does one thing, and that one thing well. Usually, bash scripts are applied with pipes. A sequence like cat x | tr a b | sort >output is much more likely and easy to handle then a single script which does all these things.
KISS with Bash is a very different approach compared to other scripting languages like Python and Perl. There you can write long code easily and conveniently. However, things can get tough when larger scripts need to be maintained.
I consider the examples in the "Bash Bible" a collection of useful black boxes. It's fine if they just work. Regarding the "unreadable" trim_string for instance, if you have problems to understand that code, and you have to change something then you can simply write your own new trim_string script, even in Python or Perl if you like. Pipes work also well with them.
Update: Another advantage of bash and pipes over Python/Perl is that the Unix system can assign each script in a pipe to a separate thread. That means, simple bash scripts with pipes can work _much_ faster than single scripts in Python or Perl.
I tend to work in Windows, Linux and MacOS pretty regularly... so I tend to follow a similar approach (node instead of python though). Windows-isms under msys(git) bash in Windows just gets painful to coordinate at times.
I am curious if people will uptake PowerShell Core (though not much of a fan there either).
I never even bothered to learn Bash properly because even that's difficult, and I figured it'd be "good mental money after bad". And, now that Python ships with all distros, I feel even less need to.
I do like Bash's range syntax though:
for i in {0..5} ; do echo $i ; done
Like Ruby's. It's so nice! D: I lament Python's lack of it.
The practice of programming in shell languages was well established when Bash was designed and Bash was definitely designed with that use in mind. So by your definition Bash is a "real" programming language.
Lisp on the other hand, was much more designed as a system and formal notation to reason about certain classes of logic problems.. So, Lisp is not a "real" language?
By "programming language" he probably means something that has robust flow control mechanisms and metaprogramming facilities.
You can definitely tell there's a different "feel" to bash and Tcl, Python, Perl, Go, etc, yes? Shell languages basically evolved out of batch processing languages that were meant to only run programs in sequence and it shows.
My disclaimer is that I love bash. I write way too many things in bash. But eventually I go back and refactor the scripts into Python (or lately, Go) because I am so sick of people refusing to touch my bash scripts.
String munging in Python is so much objectively easier to read than bash. I would say that it's because it is similar to a lot of the more popular languages than the sort of cryptic parameter substitution bash provides. And if that makes it easier to maintain some automation, then its worth the effort just to use Python IMO.
Couldn't agree more, but honestly I think that is a completely overplayed issue. Just be explicit (This requires Python3.7) and have a requirements.txt file, maybe bundle with a `make install` command and move on.
If people can't figure that out... I don't know how you're going to expect them to read a cryptic bash script.
Don't get me wrong there is totally some good use cases for bash. Init-scripts come to mind when you don't want to lug around a Python VM in a lightweight container, for example.
I don't think it's a matter of familiarity. Most of us here have used multiple languages, and I have no problem saying that the Bash syntax is atrocious.
"How do we close a statement.... errr. Let's spell it backwards".
How is it not a matter of familiarity? Just because it's not intuitive to you doesn't mean it's bad. I find anything not in an S-expression to be atrocious. Doesn't mean I can't learn and understand "horrible" syntax where I have to separate things with semicolons...
That's an argument for types. While it's more convenient to use a language without types it's more error prone. So I guess in the end strong typing wins.
>>> 0 + 42
42
>>> "0" + "42"
'042'
>>> "0" + 42
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: cannot concatenate 'str' and 'int' objects
>>> int("0") + 42
42
