4 ms·

Something I've come to internalize over the years is to always try to avoid being clever especially with lingua francas like Bash. There will be people - seaso

by lhorie 6y ago

Something I've come to internalize over the years is to always try to avoid being clever especially with lingua francas like Bash. There will be people - seasoned professional developers, even - reading these languages that don't know the first thing about them! `[` is one of those things that are second nature for seasoned bash people but that are utterly ungoogleable by a bash beginner. Beginners don't know `[` is an executable, and it would never occur to them to `man [`. It can become quite the rabbit hole to figure out that there's also `[[` (which is NOT an executable), that `[ a > b ]` is very very different from `[[ a > b ]]`, etc. So do these people a favor and put the `if` there so they at least have some hope of stumbling upon a stack overflow post talking about some of this stuff.

kwhitefoot 6y ago
'[' is a Bash builtin. See https://www.computerhope.com/unix/bash/index.htm https://www.computerhope.com/unix/bash/index.htm. It is usually also a symlink to the 'test' executable but not in all Unix-like systems.
js2 6y ago
"test" and its alias "[" are actually builtins: https://www.gnu.org/software/bash/manual/html_node/Bourne-Shell-Builtins.html https://www.gnu.org/software/bash/manual/html_node/Bourne-Sh... They also exist as executables for ancient backwards compatibility. "[[" is a so-called "conditional construct": https://www.gnu.org/software/bash/manual/html_node/Conditional-Constructs.html#Conditional-Constructs https://www.gnu.org/software/bash/manual/html_node/Condition... I have a somewhat quirky style and almost always use "if test ..." since I find it clearer than "[" and usually don't need the additional functionality that "[[" provides.
- hagg3n 6y ago
  I honestly thought I was the only one, how cool is that? I too find `test` preferable over `[` since it leaves no doubt we're calling a command just like any other and the same assumptions still apply. I also avoid `[[` since it isn't posix and won't work in simpler shells.
  - tpoacher 6y ago
    same
- waterhouse 6y ago
  I always use "test" and never "[" (and I've only used "[[" once when I thought I needed a builtin regex matcher for efficiency). Partly because fish does the same, partly because despite writing bash scripts for years I do not want to have the "[ vs [[" information in my brain (nor should whoever reads my code). (For similar reasons, whenever I'm grepping for a nontrivial regex, I always use egrep rather than grep, because the escaping semantics are simpler—"if it's escaped with a \, then it's not special"—and again I do not want to have the information of "which characters are special only when escaped in base grep" in my brain.)
  - boogies 6y ago
    > I do not want to have the information of "which characters are special only when escaped in base grep" in my brain Tangential but relevant to the Edit thread today were vis was mentioned, “No more {very-,}{no,}magic modes with different semantics and escaping rules. Instead we use the familiar and predictable POSIX Extended Regular Expression variant.”¹ is a real advantage over vim. ¹https://github.com/martanne/vis/wiki/Differences-from-Vi(m)#posix-extended-regular-expressions-instead-of-a-custom-non-standard-variation https://github.com/martanne/vis/wiki/Differences-from-Vi(m)#...
l0b0 6y ago
$ type -a [ [ is a shell builtin [ is /usr/bin/[ $ type -a [[ [[ is a shell keyword
andreareina 6y ago
The one that usually gets me is built-ins shadowing binaries, such that `man time` doesn't actually give me the info I need.
- vdm 6y ago
  I had this problem as well until I learned to use `type time`, to help me decide whether I need `man time` or `help time` (documenting the built-in)
srswtf123 6y ago
You can be clever in personal files, say ~/.bash_profile — for your user personally. But never in scripts used in production that must be maintained by a group. That rule served me well for many years. YMMV
cma 6y ago
Hopefully people wouldn't give up at that and instead search something like "bash syntax" and find the manual : https://www.gnu.org/software/bash/manual/bash.html#Bash-Conditional-Expressions https://www.gnu.org/software/bash/manual/bash.html#Bash-Cond...
interfixus 6y ago
Couldn't agree more. As a very occasional bash script user (who'll go with Python instead whenever possible) I sort of lost interest already at the first, banale example: >>if [ -r ~/.profile ]; then >> source ~/.profile >>fi >>We can simplify this using control operators: >>[ -r ~/.profile ] && . ~/.profile I wonder which version I would prefer for readability three months down the road.

by lhorie 6y ago

kwhitefoot 6y ago

'[' is a Bash builtin. See https://www.computerhope.com/unix/bash/index.htm https://www.computerhope.com/unix/bash/index.htm. It is usually also a symlink to the 'test' executable but not in all Unix-like systems.

js2 6y ago

"test" and its alias "[" are actually builtins: https://www.gnu.org/software/bash/manual/html_node/Bourne-Shell-Builtins.html https://www.gnu.org/software/bash/manual/html_node/Bourne-Sh... They also exist as executables for ancient backwards compatibility. "[[" is a so-called "conditional construct": https://www.gnu.org/software/bash/manual/html_node/Conditional-Constructs.html#Conditional-Constructs https://www.gnu.org/software/bash/manual/html_node/Condition... I have a somewhat quirky style and almost always use "if test ..." since I find it clearer than "[" and usually don't need the additional functionality that "[[" provides.

hagg3n 6y ago
I honestly thought I was the only one, how cool is that? I too find `test` preferable over `[` since it leaves no doubt we're calling a command just like any other and the same assumptions still apply. I also avoid `[[` since it isn't posix and won't work in simpler shells.
- tpoacher 6y ago
  same
waterhouse 6y ago
I always use "test" and never "[" (and I've only used "[[" once when I thought I needed a builtin regex matcher for efficiency). Partly because fish does the same, partly because despite writing bash scripts for years I do not want to have the "[ vs [[" information in my brain (nor should whoever reads my code). (For similar reasons, whenever I'm grepping for a nontrivial regex, I always use egrep rather than grep, because the escaping semantics are simpler—"if it's escaped with a \, then it's not special"—and again I do not want to have the information of "which characters are special only when escaped in base grep" in my brain.)
- boogies 6y ago
  > I do not want to have the information of "which characters are special only when escaped in base grep" in my brain Tangential but relevant to the Edit thread today were vis was mentioned, “No more {very-,}{no,}magic modes with different semantics and escaping rules. Instead we use the familiar and predictable POSIX Extended Regular Expression variant.”¹ is a real advantage over vim. ¹https://github.com/martanne/vis/wiki/Differences-from-Vi(m)#posix-extended-regular-expressions-instead-of-a-custom-non-standard-variation https://github.com/martanne/vis/wiki/Differences-from-Vi(m)#...

l0b0 6y ago

$ type -a [ [ is a shell builtin [ is /usr/bin/[ $ type -a [[ [[ is a shell keyword

andreareina 6y ago

The one that usually gets me is built-ins shadowing binaries, such that `man time` doesn't actually give me the info I need.

vdm 6y ago
I had this problem as well until I learned to use `type time`, to help me decide whether I need `man time` or `help time` (documenting the built-in)

srswtf123 6y ago

You can be clever in personal files, say ~/.bash_profile — for your user personally. But never in scripts used in production that must be maintained by a group. That rule served me well for many years. YMMV

cma 6y ago

Hopefully people wouldn't give up at that and instead search something like "bash syntax" and find the manual : https://www.gnu.org/software/bash/manual/bash.html#Bash-Conditional-Expressions https://www.gnu.org/software/bash/manual/bash.html#Bash-Cond...

interfixus 6y ago

Couldn't agree more. As a very occasional bash script user (who'll go with Python instead whenever possible) I sort of lost interest already at the first, banale example: >>if [ -r ~/.profile ]; then >> source ~/.profile >>fi >>We can simplify this using control operators: >>[ -r ~/.profile ] && . ~/.profile I wonder which version I would prefer for readability three months down the road.