3 ms·

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 refus

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

dllthomas 6y ago
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
- gricardo99 6y ago
  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 ...
  - fl0wenol 6y ago
    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.
  - dllthomas 6y ago
    From one perspective, if [ $? -eq 0 ]; then ... is actually an instance of if COMMAND; then ... because [ is itself a command.
    - gricardo99 6y ago
      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.

dllthomas 6y ago

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

gricardo99 6y ago
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 ...
- fl0wenol 6y ago
  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.
- dllthomas 6y ago
  From one perspective, if [ $? -eq 0 ]; then ... is actually an instance of if COMMAND; then ... because [ is itself a command.
  - gricardo99 6y ago
    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.