1

I've found such behavior of bash GNU bash, version 4.3.30(1)-release (x86_64-pc-linux-gnu) and even latest ( How to get version of dash? ) dash on Debian.

Bug as is:

/bin/echo "Silent Err 'unexpected EOF while looking for matching' Example:"

if [ 0 -eq 1 ]; then
        /bin/echo "HERE IS MISTAKE WITHOUT QUOTE IN THE END
        exit
fi

/bin/echo " BLACK HOLE "
/bin/echo " CODE WILL NEVER PROCEED "

if [ 0 -eq 1 ]; then
        /bin/echo "SECOND MISTAKE
        exit
fi
/bin/echo "normal code... will work";
/bin/echo "Good and silent exit without any notice about BLACK HOLE code..."
/bin/echo "exit."

Launching:

# bash bug_as_is.sh 
Silent Err 'unexpected EOF while looking for matching' Example:
normal code... will work
Good and silent exit without any notice about BLACK HOLE code place...
exit.

Only if the first if then fi block will be quoted, than error appears:

# bash unbug.sh 
Silent Err 'unexpected EOF while looking for matching' Example:
 BLACK HOLE 
 CODE WILL NEVER PROCEED 
unbug.sh: line 20: unexpected EOF while looking for matching `"'
unbug.sh: line 24: syntax error: unexpected end of file

Is it common known bug or I've found real diamond? (;

And what is backbone of this behavior?

1
  • The fact that BLACK HOLE etc is printed is not a bug, what makes you think it is? Hint: look at the syntax highlighting in your editor, or even in your question. Oct 26, 2015 at 20:58

2 Answers 2

3

There is no bug in bash: the code is working just as it should.

bash allows multi-line strings as arguments to echo even if those strings look odd and contain what would otherwise be bash code.

Note that the following is simply one echo statement with a multiline string for output:

        /bin/echo "HERE IS MISTAKE WITHOUT QUOTE IN THE END
        exit
fi

/bin/echo " BLACK HOLE "
/bin/echo " CODE WILL NEVER PROCEED "

if [ 0 -eq 1 ]; then
        /bin/echo "SECOND MISTAKE

To clarify, let's replace that long string with "multiline string omitted". Then, the code is simply:

/bin/echo "Silent Err 'unexpected EOF while looking for matching' Example:"

if [ 0 -eq 1 ]; then
        /bin/echo "multiline string omitted"
        exit
fi
/bin/echo "normal code... will work";
/bin/echo "Good and silent exit without any notice about BLACK HOLE code..."
/bin/echo "exit."

The above is properly working code.

1

I'm not sure what "backbone of this behavior" means, but as I interpret it:

The (seemingly) unmatched quoted string "HERE IS MISTAKE WITHOUT QUOTE IN THE END actually just starts a quoted string literal. That string literal goes past the first fi and encompasses everything up to the double quote character that begins "SECOND MISTAKE.

So, bash can parse the whole mess, albeit improperly from a human standpoint. It does turn out, since 1 does not numerically equate to 0, that the entire block of code, from /bin/echo "HERE IS MISTAKE to the fi following "SECOND MISTAKE does not get executed. So the (apparent) string SECOND MISTAKE is parsed correctly, as a possible command, but bash never tries to execute it, so we don't see an error about SECOND: command not found or whatever.

Just to summarize, the missing quotes on two lines cause bash to parse the code as the "true" clause of a single if-then-fi, but the condition is false, so bash never tries to execute what the human eye sees as a bad command, and doesn't give a relevant syntax error.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .