6 ms·
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 mo
by serhart 7y ago
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.
- mankyd 7y agoI'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.
- zests 7y agoSingle 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.
- joombaga 7y agoYou 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.
- serhart 7y agoI'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.
- pretendscholar 7y agoI 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.
- serhart 7y agoYes, 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.
- pretendscholar 7y agowhich 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.
- serhart 7y agoI 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
- cblades 7y agoMaybe "unreadable" and "readable" aren't the best ways to approach this conversation. It's certainly less readable than, say, my_str.strip()
- serhart 7y agoSure, 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.
- jigglesniggle 7y agoI 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.
- mankyd 7y agoMy (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.
- dec0dedab0de 7y agoMy rule of thumb is to use a real language if there is more than one if fi block.
- jascii 7y agoSo, what in your opinion constitutes a "real language", and why?
- dec0dedab0de 7y agoa "real language" would be any programming language that is primarily designed and presented as a programming language.
- jascii 7y agoNice recursive definition.. 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?
- cfors 7y agoMy 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.
- fsaintjacques 7y agoPython is a portability minefield. I'll spend more time trying to get the script/package run than reading the bash script.
- cfors 7y agoCouldn'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.
- tynorf 7y ago> Just be explicit (This requires Python3.7) Or just use a `#!/usr/bin/env python3.7` shebang.
- fhood 7y ago"Almost any language will look cryptic if you don’t know it." Seems disingenuous to me. Java and Python are in a different class of readability than Bash or Perl. Example: "abc" + "def" = "abcdef" vs "abc"."def" = "abcdef"
- lizmat 7y ago> "abc" + "def" = "abcdef" vs "abc" . "def" = "abcdef" Would be better comparison if you would use whitespace in the other case as well. Which then makes it just as readable. Also. "0" + "42" would that be "042" or 42? It may be better readable, but the semantics are unclear.
- ofrzeta 7y agoThat'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
- papito 7y agoI 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".
- throwaway_se099 7y ago> "How do we close a statement.... errr. Let's spell it backwards". That's on the original Bourne shell and its author's evident love for Algol 68. Wikipedia has a fine summary.
- serhart 7y agoHow 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...
- papito 7y agoI am saying, we are allowed to have an opinion on it. You can be good at something and still acknowledge that is sucks.