A testament to the brokenness of making `[` a command

I prefer to always use the `test` command instead (it’s the exact equivalent of `[`), and never use `[[` bashisms (well, almost never).

And here I thought I was the only one!

I also do this.

shellcheck has this to say:

    In exec.sh line 1:
    if [ exec 1>/dev/null 2>/dev/null 3>/dev/tcp/localhost/4000 ] ; then
    ^-- SC1009: The mentioned syntax error was in this if expression.
       ^-- SC1073: Couldn't parse this test expression. Fix to allow more checks.
         ^-- SC1014: Use 'if cmd; then ..' to check exit code, or 'if [[ $(cmd) == .. ]]' to check output.
              ^-- SC1072: Expected test to end here (don't wrap commands in []/[[]]). Fix any mentioned problems and try again.
    
    For more information:
      https://www.shellcheck.net/wiki/SC1014 -- Use 'if cmd; then ..' to check ex...
      https://www.shellcheck.net/wiki/SC1072 -- Expected test to end here (don't ...
      https://www.shellcheck.net/wiki/SC1073 -- Couldn't parse this test expressi...

Hey I'm the author - I did not know about this! I suppose I should have guessed somebody made a shell script linter at some point though. Very useful!

I'm not sure if the code example changed on the linked page after your comment, but I see this code:

  #!/bin/bash
  if exec 3>/dev/tcp/localhost/4000 ; then
 echo "server up!"
  else
 echo "server down."
  fi

Which also confused me for similar reasons to your comment. I'm not familiar with exec, but generally non-zero return means a fail, and zero means success. So why is the "server up" for non-zero result?

Sure enough, I tested this, and the server up/down is reversed from what it should be:

   > exec 3>/dev/tcp/localhost/4000
     bash: connect: Connection refused
     bash: /dev/tcp/localhost/4000: Connection refused
   > echo $?
    1

But if a localhost port is listening (in another terminal window: > nc -l localhost 4000):

   > exec 3>/dev/tcp/localhost/4000
   > echo $?
     0

In the quoted code, "server up" is for a zero result - `if` is reversed from what you think it is:

    > if true; then echo yup; fi
    yup
    > true
    > echo $?
    0

indeed you are right. Thanks for the reply. I'm too accustomed to seeing code like:

  if [ $? -eq 0 ]; then echo "pass";else echo "fail";fi

But without the expression '[ ... ]' shell/bash does indeed treat zero return code (success) as boolean true. For whatever reason I have not seen much (if any) bash code that simply uses:

  if COMMAND; then ...

You really really should use if COMMAND logic, in the event that all you care about is zero or non-zero result. I find it easier to follow for shell control flow.

It also works for shell functions.

From one perspective,

    if [ $? -eq 0 ]; then ...

is actually an instance of

    if COMMAND; then ...

because [ is itself a command.

yep, I think that's the key point I need to drill into my head. The unix/linux idiom where 0 is true/success and non-zero is a failure can be counter-intuitive when combined with "if" (at least for me, hence my mistake reading the code). In most/other computing contexts "if 0" is never taken. I think this might explain why I've seen a lot more bash code that is explicitly written in the form more familiar to "if" usage in other languages (pseudo-code): "if res == 0". But "if COMMAND" is taking care of the interpretation of the return code, so doing the explicit compare is redundant.

Hey I'm the author. Bash treats 0 exit codes as a success, so the "server up" echo runs if the connection is made.

Hi I'm the author! Yes, I wrote this code quite quickly and when I originally posted this on reddit someone pointed out my mistake. The more you know, I suppose.