10 ms·

I have a personal dislike for regexes and non human readable code, it gives maintenance headache. It's why I avoid shell scripts as much as possible. The first

I have a personal dislike for regexes and non human readable code, it gives maintenance headache. It's why I avoid shell scripts as much as possible. The first example is not human readable, if the name of the function is a lie, I have no idea what this piece of code do : trim_string() { : "${1#"${1%%[![:space:]]*}"}" : "${_%"${_##*[![:space:]]}"}" printf '%s\n' "$_" }

0x0aff374668 7y ago
"maintenance headache." Then stop maintaining code from languages you don't understand. This is frustrating. I've seen solutions on the comments that call PYTHON! Are you effing kidding me? PYTHON ?? Granted, BASH docs aren't particularly succinct, but shell scripts are an absolute necessity in the OS world. It's pretty simple: If you don't understand shellcode, don't maintain an OS, or rather, don't expect to be accommodated for lack of knowledge for something that's been standard for 30+ years.
Too 7y ago
I only got to the first example and had a hard time deciding if the article was satire or not. Let's use bash instead of a real programming language! It is super convenient! To do super fundamental things like trimming strings you just have to implement your own function with 40+ non-ASCII characters in a row! That example makes regexps seem like human readable and god knows if it is even correct or works portably across different versions of bash. To be fair the article assumes you are first in bash and want to avoid launching subprocesses but for any production scripting that is the wrong hypothesis to begin with. A better approach would be to not start inside bash at all. Just do your scripting in a higher level language where basic ABC stuff like string, list, number and error handling are already there for you. Even if that trim_string function and everything else from the article would be provided in some bash-bible-std-lib it wouldn't even come close to what's available in say Python for example, and you still have to wrestle the syntax and other obscurities like -a (or -e) meaning file exists. While there are some good examples in there if you are stuck in bash, this article was more of a 100 reasons not to use bash to me.
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 ago
  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.
  - zests 7y ago
    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.
    - joombaga 7y ago
      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.
  - serhart 7y ago
    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.
    - 7y ago
inimino 7y ago
I have a personal dislike for "non human readable" used as shorthand for "not immediately and easily readable by me".
- deschutes 7y ago
  The human part is a hyperbole. "This code is unreadable" implies "This code is unreadable for the intended audience." Here's how I'd write that function: trim_string() { python3 -c 'import sys; sys.stdout.write(sys.argv[1].strip())' "$1" }
  - ulysses 7y ago
    "A collection of pure bash alternatives to external processes."
    - munk-a 7y ago
      It is a neat academic exercise to find these but I think that's sort of the point - why? If you're building something that multiple folks will be reading and using just call out to external processes and make it easier to follow what's going on. It's neat to know how to do these things, but they're honestly a bit of a security hole because a large portion of folks using them will never comprehend the why and how and just assume it's doing the proper what.
      - jascii 7y ago
        Why? No external dependencies, your code can run anywhere you have a Bash shell. This also means a smaller attack surface. Also readability: While some of the examples may be somewhat confusing to someone who doesn't have a lot of Bash experience, to someone who does it can be a lot more readable then feeding a string in yet another language to an external program and processing the output..
        munk-a 7y ago
        Sed exists everywhere for a reasonably complete definition of everywhere - if it doesn't exist then you probably don't have access to Bash (and definitely not a fully featured one)
chapium 7y ago
Perhaps it shouldnt be defined as what the regex can do, but which unit tests its able to pass.
deleted 7y ago
[deleted]
seamyb88 7y ago
> It's why I avoid shell scripts as much as possible. This is all from somebody who has just written a linux user space. Perhaps the author avoids shell as much as possible. It just isn't possible. I doubt it, though. Bash is awesome.
peterwwillis 7y ago
Is the following a maintenance headache, or non-human readable? #!/bin/sh FOO=" some long string here " FOO="$( echo "$FOO" | sed -e ' s/^[[:space:]]//g; s/[[:space:]]$//g ' )" This isn't "pure bash", but most of what I write in shell scripts isn't "pure bash". It's shell scripting: dirty, slow, easy, effective. Like any 'language', it takes on the complexity you put into it. English is really complicated, but you can also use a subset of it with only 850, 1200, or 2400 words, and suddenly it's very simple and clear.
- jwilk 7y ago
  Unlike the original code, this strips whitespace from every line of input.
- jolmg 7y ago
  > echo "$FOO" | sed -e ' s/^[[:space:]]//g; s/[[:space:]]$//g ' Your example fails when $FOO is "-n", for instance. Also the g modifiers are redundant in your example since there's only one beginning of line per line and one end of line per line. I would instead write this: sed -r 's/^\s+|\s+$//g' <<< "$FOO" EDIT: I think I see now what you probably thought would happen by using g, but no it wouldn't remove multiple spaces. So, you example also fails when $FOO is " x" (using 2 or more spaces at the ends).
  - jwilk 7y ago
    Beware that -r is a GNU-specific option.
Koshkin 7y ago
It might be worth it to learn it though, even if just for fun.
soheil 7y ago
Do you have a personal dislike for math too?
deleted 7y ago
[deleted]
imihai1988 7y ago
those are not regexes though, are they ? apart from the [:space:] part
dredmorbius 7y ago
My inner pedant compels me to reply that these are not in fact regexes, but Bash parameter expansions. https://www.gnu.org/software/bash/manual/html_node/Shell-Parameter-Expansion.html https://www.gnu.org/software/bash/manual/html_node/Shell-Par... My inner pedant has no comment regarding readability of Bash parameter expansions.
kamaal 7y ago
On the contrary regexes were invented because you shouldn't have to write 500 lines of code for that which can be done in two lines. If we didn't have regexes we would have 100s of if/else's scattered all over program logic. That would be more hard to handle than the regex itself.
5Qn8mNbc2FNCiVV 7y ago
And it doesn't have to be. There should be trust that the function does what it says. If I use `printf` and don't understand how it's working internally it doesn't matter to me because I know what it does and trust it. These scripts/snippets for me are just an unofficial extended standard lib

0x0aff374668 7y ago

"maintenance headache." Then stop maintaining code from languages you don't understand. This is frustrating. I've seen solutions on the comments that call PYTHON! Are you effing kidding me? PYTHON ?? Granted, BASH docs aren't particularly succinct, but shell scripts are an absolute necessity in the OS world. It's pretty simple: If you don't understand shellcode, don't maintain an OS, or rather, don't expect to be accommodated for lack of knowledge for something that's been standard for 30+ years.

Too 7y ago

I only got to the first example and had a hard time deciding if the article was satire or not. Let's use bash instead of a real programming language! It is super convenient! To do super fundamental things like trimming strings you just have to implement your own function with 40+ non-ASCII characters in a row! That example makes regexps seem like human readable and god knows if it is even correct or works portably across different versions of bash. To be fair the article assumes you are first in bash and want to avoid launching subprocesses but for any production scripting that is the wrong hypothesis to begin with. A better approach would be to not start inside bash at all. Just do your scripting in a higher level language where basic ABC stuff like string, list, number and error handling are already there for you. Even if that trim_string function and everything else from the article would be provided in some bash-bible-std-lib it wouldn't even come close to what's available in say Python for example, and you still have to wrestle the syntax and other obscurities like -a (or -e) meaning file exists. While there are some good examples in there if you are stuck in bash, this article was more of a 100 reasons not to use bash to me.

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 ago
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.
- zests 7y ago
  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.
  - joombaga 7y ago
    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.
- serhart 7y ago
  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.
  - 7y ago

inimino 7y ago

I have a personal dislike for "non human readable" used as shorthand for "not immediately and easily readable by me".

deschutes 7y ago
The human part is a hyperbole. "This code is unreadable" implies "This code is unreadable for the intended audience." Here's how I'd write that function: trim_string() { python3 -c 'import sys; sys.stdout.write(sys.argv[1].strip())' "$1" }
- ulysses 7y ago
  "A collection of pure bash alternatives to external processes."
  - munk-a 7y ago
    It is a neat academic exercise to find these but I think that's sort of the point - why? If you're building something that multiple folks will be reading and using just call out to external processes and make it easier to follow what's going on. It's neat to know how to do these things, but they're honestly a bit of a security hole because a large portion of folks using them will never comprehend the why and how and just assume it's doing the proper what.
    - jascii 7y ago
      Why? No external dependencies, your code can run anywhere you have a Bash shell. This also means a smaller attack surface. Also readability: While some of the examples may be somewhat confusing to someone who doesn't have a lot of Bash experience, to someone who does it can be a lot more readable then feeding a string in yet another language to an external program and processing the output..
      - munk-a 7y ago
        Sed exists everywhere for a reasonably complete definition of everywhere - if it doesn't exist then you probably don't have access to Bash (and definitely not a fully featured one)

chapium 7y ago

Perhaps it shouldnt be defined as what the regex can do, but which unit tests its able to pass.

deleted 7y ago

[deleted]

seamyb88 7y ago

> It's why I avoid shell scripts as much as possible. This is all from somebody who has just written a linux user space. Perhaps the author avoids shell as much as possible. It just isn't possible. I doubt it, though. Bash is awesome.

peterwwillis 7y ago

Is the following a maintenance headache, or non-human readable? #!/bin/sh FOO=" some long string here " FOO="$( echo "$FOO" | sed -e ' s/^[[:space:]]//g; s/[[:space:]]$//g ' )" This isn't "pure bash", but most of what I write in shell scripts isn't "pure bash". It's shell scripting: dirty, slow, easy, effective. Like any 'language', it takes on the complexity you put into it. English is really complicated, but you can also use a subset of it with only 850, 1200, or 2400 words, and suddenly it's very simple and clear.

jwilk 7y ago
Unlike the original code, this strips whitespace from every line of input.
jolmg 7y ago
> echo "$FOO" | sed -e ' s/^[[:space:]]//g; s/[[:space:]]$//g ' Your example fails when $FOO is "-n", for instance. Also the g modifiers are redundant in your example since there's only one beginning of line per line and one end of line per line. I would instead write this: sed -r 's/^\s+|\s+$//g' <<< "$FOO" EDIT: I think I see now what you probably thought would happen by using g, but no it wouldn't remove multiple spaces. So, you example also fails when $FOO is " x" (using 2 or more spaces at the ends).
- jwilk 7y ago
  Beware that -r is a GNU-specific option.

Koshkin 7y ago

It might be worth it to learn it though, even if just for fun.

soheil 7y ago

Do you have a personal dislike for math too?

deleted 7y ago

[deleted]

imihai1988 7y ago

those are not regexes though, are they ? apart from the [:space:] part

dredmorbius 7y ago

My inner pedant compels me to reply that these are not in fact regexes, but Bash parameter expansions. https://www.gnu.org/software/bash/manual/html_node/Shell-Parameter-Expansion.html https://www.gnu.org/software/bash/manual/html_node/Shell-Par... My inner pedant has no comment regarding readability of Bash parameter expansions.

kamaal 7y ago

On the contrary regexes were invented because you shouldn't have to write 500 lines of code for that which can be done in two lines. If we didn't have regexes we would have 100s of if/else's scattered all over program logic. That would be more hard to handle than the regex itself.

5Qn8mNbc2FNCiVV 7y ago

And it doesn't have to be. There should be trust that the function does what it says. If I use `printf` and don't understand how it's working internally it doesn't matter to me because I know what it does and trust it. These scripts/snippets for me are just an unofficial extended standard lib