13995 2020-08-03 10:40:44 +0000 \ without a newline passes the parser 2025-01-04 11:50:49 +0000 1 1 7 Build System, Metadata & Runtime BitBake bitbake unspecified x86 Multiple NEW Medium normal 5.99 1 kweihmann unassigned akuster mark.asselstine poky.bs.watcher poky.watcher randy.macleod --- --- No (bug/feature does not impact docs) oldest_to_newest 87874 0 kweihmann 2020-08-03 10:40:44 +0000 A statement like 'A = "a b c \"' passes the parser, although '\' should be an undesired symbol in the final variable. 'A = "a b c \\n"' on the other hand is correctly expanded into the desired state of 'A = "a b c "' 97098 1 randy.macleod 2023-10-30 15:37:24 +0000 Build move to 5.0 -- ../Randy 98819 2 randy.macleod 2024-04-25 01:13:52 +0000 Bulk move of 5.0 medium importance issues to 5.99. Move to 5.1 if you want to actively work on an issue. 98859 3 randy.macleod 2024-04-25 01:23:11 +0000 Move to 5.99 since no one is actively working on this issue. Move to 5.x if you start on a task, please. 100514 4 mark.asselstine 2024-12-28 16:14:59 +0000 (In reply to kweihmann from comment #0) > A statement like 'A = "a b c \"' passes the parser, although '\' should be > an undesired symbol in the final variable. > 'A = "a b c \\n"' on the other hand is correctly expanded into the desired > state of 'A = "a b c "' Can you expand on "undesired symbol"? According to the documentation - https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-metadata.html#line-joining "BitBake joins any line ending in a backslash character (”\”) with the following line before parsing statements". In your example the '\' is not the last character, so does not trigger line joining. Additionally "BitBake does not interpret escape sequences like “\n” in variable values.". As such the single '\' is essentially dropped from the string, as is happening. Thus my question, what is it that you are expecting to see? 100521 5 kweihmann 2025-01-03 07:36:35 +0000 'A = "a b c \"' literally remains 'A = "a b c \"' after parsing. As in the statement it is the end of the line, I would expect it to be 'A = "a b c"' after parsing, but it isn't - and that's the bug for me, as I read the documentation in that way, that it will remove '\' from the output. The '\n' was just for illustration of the issue 100531 6 mark.asselstine 2025-01-03 15:52:56 +0000 Thanks for the additional information. Just so we are clear, for: A = "a b c \" The " character is the last character of the line The \ character is the last character of the string So again referring to the manual in the "Line Joining" section there is a NOTE "BitBake does not interpret escape sequences like “\n” in variable values. For these to have an effect, the value must be passed to some utility that interprets escape sequences, such as printf or echo -n." Since the '\' is not the last character in the line, line joining is not applied here. Since '\' is in the string, the NOTE does apply and the escape sequence does not get interpreted. So a "\" character in the string, remains in the string. The behavior is matching the documentation and so I don't believe this is a bug. I know that you were using "\\n" to illustrate your point, but I am actually unable to reproduce your results. Building hello-world (https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-hello.html) with 'A = "a b c \\n"' in printhello.bb along with 'bb.plain(d.getVar("A"))' added to do_build() results in the string being output as "a b c \\n". Again this follows what is described in the NOTE. Are you able to provide an example which can be reproduced? PS. In my earlier comment I incorrectly said the "\" would be dropped, I had meant to say it would remain, as-is, again based on the documented behavior. 100532 7 kweihmann 2025-01-04 11:50:49 +0000 If '\"' is interpreted as an escape sequence, then I would at least expect the variable set operation to fail, as the '"a b c \"' would have an opened double quote but no closing one. None of that happens, it just will be passed on leading to in this particular case very hard to debug problems, if the value of the escape '"' will be passed on into e.g. a shell call. All of the documentation mentions '"<something something>"' or "'<something something>'" as the only valid syntax for variable ops, so I honestly believe the parser should at least pass a warning that a quote wasn't closed. And that is the bug to me