Hacker News Reader

Comment by lhorie | Hacker News Reader

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.

View on HN

"test" and its alias "[" are actually builtins:

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/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.

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.)

> 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)#...

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.

same

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

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

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.

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-Cond...

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

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)

'[' is a Bash builtin. See 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.

Reply on news.ycombinator.com