Trace statement with nested brackets turns following load script into comments

[stascher]

Hi all,

This is probably the strangest thing I've seen in 10 years of Qlik script development. 

I created a subroutine for debugging purposes that outputs the contents of a table using a TRACE statement.

The subroutine basically iterates over each record in the table, initializes a variable (ostring) and then iterates over each field and concatenates the field's value to ostring.   The subroutine surrounds the value of each field with square brackets so that I can visually differentiate the values.  After all fields in the record are iterated over, there is a  TRACE $(ostring); statement to output the record .

Normally the output looks something like [ABC] [123] [Good Day]. Pretty simple right?

But here's the weird part: One of my fields had a value that was already surrounded by square brackets so the resulting output was: [ABC][123][[Good Day]]. The strange thing is, when you have nested square brackets in a TRACE statement, it acts like a "/*" comment header and treats a good chunk of the load script following the TRACE as a comment section. 

You can try it yourself. Add the following statement to your script: TRACE [ABC][123][[Good Day]]; and see what happens. 

So is this expected/obvious behavior and I'm just overlooking something, or is this truly strange behavior and possibly a (gasp!) bug?

-Steve

[rubenmarin]

Curious. And only the final brackets seems to create this behaviour, only when there is an even number of closing brackets the next code is like part of the trace sentence.

[stascher]

Yes, after further investigation, I also noticed that as well.

[henrikalmen]

Fascinating!

This works:
trace ABC]];

But this is not working:
trace [ABC]];

[marcus_sommer]

It's really interesting. Never noticed this behaviour.

Just looked into QlikView Quoteology - Qlik Community - 1476029 and Escape sequences - Qlik Community - 1469770 to find hints - and there are, at least in regard to field- and table-names respectively in-load-statements in which such syntax is possible and valide.

But outside from the load it showed the above mentioned behaviour and not only by a trace-statement else also by creating variables. Beside this the behaviour might be bypassed by wrapping the [...]] with single- or double-quotes.

I don't know how the script-parser technically worked but I rather don't believe that's a classical bug else that's from the very old days is a not documented feature for any special purpose which wasn't removed - maybe hic could shed some light.  

[Clever_Anjos]

Really weird

[henrikalmen]

The Escape Sequences article @marcus_sommer linked to actually gives us the explanation. Two similiar square brackets next to each other renders one of them as an escape character for the second one. In other words, ]] is treated as one string formatted bracket: ']'

So  [ABC]] becomes the string 'ABC]' where the bracket I have marked red is interpreted as a string character and not as a bracket function.

[ABC]]] results in the string 'ABC]' and is therefore functional.

[marcus_sommer]

Great explanation! I had should read the postings more carefully.

[henrikalmen]

It's still a bit confusing though. The original example is [ABC][123][[Good Day]] - so what happens there?

Why does that not become sort of 'ABC' '123' '[Good Day]'?

In the post, it says "If the field name contains square brackets, e.g. a field called Name[5], only the right bracket needs to be escaped. ... Such a field can be loaded as [Name[5]]] "

It's seems likely that it is true to say that only the right bracket can be escaped. So for some reason [[Good Day]] becomes something like the string [Good Day| (I've replaced the final char with a pipe instead of bracket just to illustrate) and the first bracket never closes. But I don't think I understand why the first double bracket [[ doesn't become one escaped '[' string character. Maybe it's just a rule that [ can't act as an escape char, but ] can.