8 ms·

I’m sorry, but I almost spit my drink out at how unreadable the very first example is. trim_string() { # Usage: trim_string " example string "

I’m sorry, but I almost spit my drink out at how unreadable the very first example is. trim_string() { # Usage: trim_string " example string " : "${1#"${1%%[![:space:]]*}"}" : "${_%"${_##*[![:space:]]}"}" printf '%s\n' "$_" }

freddref 5y ago
It gets more readable the more often you read it
jamil7 5y ago
Yeah that’s pretty wild. This resource pops up here a bit and it’s cool but there’s always a point where I’m like why would I do this in Bash and not Python/Ruby or something else.
- adhesive_wombat 5y ago
  I have found my life has improved where as soon as I can't find the answer to a "wtf how do I do this trivial in shell" question after a cursory search, it's a good time to stop, and seriously consider Python (or Perl, ok, ok). Sometimes, it's genuinely better to plug on in shell (e.g. if you are just calling other scripts and chaining stuff), but, especially if you want some less-magical string or list manipulations, often Python/Perl will provide a more readable, more maintainable, more _testable_ script. YMMV with Perl.
deleted 5y ago
[deleted]
mttjj 5y ago
I mean, does it really need to be readable? I kind of took this site to be “here’s some snippets of code that you can use in your scripts to use instead of calling an external process.” Which means to me, I’m going to copy/paste this function into my script, call the function (since it’s structured as one), and never think about it again. “Learn how to write routines like this and make them readable” seems like it’s not the point of this “Bible”. I’m not against readable code by any means (maybe there’s even a cleaner way to write this) but it seemed inconsequential in my opinion.
- aloisdg 5y ago
  I am more and more on your side. If this function was a builtin, how many reader will check its implementation?
  - jteppinette 5y ago
    But it is not a builtin. Someone else is going to have to maintain this one day. > insert quote about writing your code as if the person who will have to maintain it next is a violent psychopath who knows where you live
    - adhesive_wombat 5y ago
      This maybe true even if the next person to maintain that is yourself! I have certainly wished terrible vengeance to be visited on past me.
  - throwamon 5y ago
    Totally agreed. While we're at it, let's make Brainfuck the official POSIX shell language.
- chasil 5y ago
  Ideally, the function is POSIX-compatible, so it runs on the widest number of platforms. Why do we want to adhere to POSIX? $ man bash | grep slow It's too big and too slow. $ rpm -qi dash | tail -3 DASH is a POSIX-compliant implementation of /bin/sh that aims to be as small as possible. It does this without sacrificing speed where possible. In fact, it is significantly faster than bash (the GNU Bourne-Again SHell) for most tasks. So let's find out how this function works in dash. $ ./testtrim ./testtrim $ sed -i 's/dash/bash/' testtrim $ ./testtrim foo bar I think I will pass.
  - mkdirp 5y ago
    > Ideally, the function is POSIX-compatible, so it runs on the widest number of platforms. But... Why? During my professional career of about 10 years, and even before that, I've not once had to require POSIX compatibility for any of the shell scripts I've written or come across. The few times I had a snippet that couldn't run I have been able to install bash 4+ with ease. I'm sure there are times where POSIX is kind of needed, but it's becoming exceedingly rare.
avgcorrection 5y ago
String substitution (or whatever it is called?) looks so bad in Bash. Similar to the sigils for history expansion. I’ll just stick to Up, Down, and Ctrl+R.
lubesGordi 5y ago
Bash syntax is so alien. The sentence before your example: "The : built-in is used in place of a temporary variable." So I was like wtf even before you spit your drink. Maybe someone can claim there's efficiency here?
- chasil 5y ago
  It's actually a "no-op" -try it. if [ -z "$foo" ] then : else echo not blank "$foo" fi
  - mrspuratic 5y ago
    It is intrinsically a nop, but its context can have side effects because it's still a real command. One side effect is exploited here: setting $_ to the last argument of the previous command. The first description in the article of its use is unhelpful, it's not until the end in "Simpler case statement" that it's made clear. I often use it instead of truncate or touch : > somefile : >> somefile : is not lexically special (the way # is), you can use : in variable and function names, even create a function called just ":" if you're trying to confuse...
INTPenis 5y ago
Oh god, you know you've become anal about bash when you can actually vaguely understand what is going on. I mean it's parameter expansion, just flip down to that section of the manpage, and then there is posix regex in there. Not too difficult to look up in the manpages.
deleted 5y ago
[deleted]
pavon 5y ago
To be fair that is one of the worst. I'm definitely bookmarking this site. Even if I won't use several of the functions, it is really valuable to have a single place to check to see "yeah, that really is the best you can do with bash, I'll exec out instead", rather than scouring through multiple StackOverflow answers that are subtly wrong. And my bash code would probably be more readable if I started collecting common operations in a function library rather than repeating the same sed/awk incantations that aren't super readable. At that point might as well use pure bash/sh implementations to save spawning a new process when reasonable.

freddref 5y ago

It gets more readable the more often you read it

jamil7 5y ago

Yeah that’s pretty wild. This resource pops up here a bit and it’s cool but there’s always a point where I’m like why would I do this in Bash and not Python/Ruby or something else.

adhesive_wombat 5y ago
I have found my life has improved where as soon as I can't find the answer to a "wtf how do I do this trivial in shell" question after a cursory search, it's a good time to stop, and seriously consider Python (or Perl, ok, ok). Sometimes, it's genuinely better to plug on in shell (e.g. if you are just calling other scripts and chaining stuff), but, especially if you want some less-magical string or list manipulations, often Python/Perl will provide a more readable, more maintainable, more _testable_ script. YMMV with Perl.

deleted 5y ago

[deleted]

mttjj 5y ago

I mean, does it really need to be readable? I kind of took this site to be “here’s some snippets of code that you can use in your scripts to use instead of calling an external process.” Which means to me, I’m going to copy/paste this function into my script, call the function (since it’s structured as one), and never think about it again. “Learn how to write routines like this and make them readable” seems like it’s not the point of this “Bible”. I’m not against readable code by any means (maybe there’s even a cleaner way to write this) but it seemed inconsequential in my opinion.

aloisdg 5y ago
I am more and more on your side. If this function was a builtin, how many reader will check its implementation?
- jteppinette 5y ago
  But it is not a builtin. Someone else is going to have to maintain this one day. > insert quote about writing your code as if the person who will have to maintain it next is a violent psychopath who knows where you live
  - adhesive_wombat 5y ago
    This maybe true even if the next person to maintain that is yourself! I have certainly wished terrible vengeance to be visited on past me.
- throwamon 5y ago
  Totally agreed. While we're at it, let's make Brainfuck the official POSIX shell language.
chasil 5y ago
Ideally, the function is POSIX-compatible, so it runs on the widest number of platforms. Why do we want to adhere to POSIX? $ man bash | grep slow It's too big and too slow. $ rpm -qi dash | tail -3 DASH is a POSIX-compliant implementation of /bin/sh that aims to be as small as possible. It does this without sacrificing speed where possible. In fact, it is significantly faster than bash (the GNU Bourne-Again SHell) for most tasks. So let's find out how this function works in dash. $ ./testtrim ./testtrim $ sed -i 's/dash/bash/' testtrim $ ./testtrim foo bar I think I will pass.
- mkdirp 5y ago
  > Ideally, the function is POSIX-compatible, so it runs on the widest number of platforms. But... Why? During my professional career of about 10 years, and even before that, I've not once had to require POSIX compatibility for any of the shell scripts I've written or come across. The few times I had a snippet that couldn't run I have been able to install bash 4+ with ease. I'm sure there are times where POSIX is kind of needed, but it's becoming exceedingly rare.

avgcorrection 5y ago

String substitution (or whatever it is called?) looks so bad in Bash. Similar to the sigils for history expansion. I’ll just stick to Up, Down, and Ctrl+R.

lubesGordi 5y ago

Bash syntax is so alien. The sentence before your example: "The : built-in is used in place of a temporary variable." So I was like wtf even before you spit your drink. Maybe someone can claim there's efficiency here?

chasil 5y ago
It's actually a "no-op" -try it. if [ -z "$foo" ] then : else echo not blank "$foo" fi
- mrspuratic 5y ago
  It is intrinsically a nop, but its context can have side effects because it's still a real command. One side effect is exploited here: setting $_ to the last argument of the previous command. The first description in the article of its use is unhelpful, it's not until the end in "Simpler case statement" that it's made clear. I often use it instead of truncate or touch : > somefile : >> somefile : is not lexically special (the way # is), you can use : in variable and function names, even create a function called just ":" if you're trying to confuse...

INTPenis 5y ago

Oh god, you know you've become anal about bash when you can actually vaguely understand what is going on. I mean it's parameter expansion, just flip down to that section of the manpage, and then there is posix regex in there. Not too difficult to look up in the manpages.

deleted 5y ago

[deleted]

pavon 5y ago

To be fair that is one of the worst. I'm definitely bookmarking this site. Even if I won't use several of the functions, it is really valuable to have a single place to check to see "yeah, that really is the best you can do with bash, I'll exec out instead", rather than scouring through multiple StackOverflow answers that are subtly wrong. And my bash code would probably be more readable if I started collecting common operations in a function library rather than repeating the same sed/awk incantations that aren't super readable. At that point might as well use pure bash/sh implementations to save spawning a new process when reasonable.