You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Comments inside one-line backtick command expansions are not parsed properly -> # comment #116
When there is a comment inside `backticks`, the comment continues to the end of the line, rather than stopping at the closing backtick.
Example:
$ echo`echo hey # comment` there
hey there
Note the difference from the $() style of command substitution:
$ echo$(echo hey # comment) there)
hey
The first of these examples is the problematic one.
If you are wondering why anyone would do this, I have seen this technique used as a way of putting comments in tight places, like inside parts of pipelines.
$ printf'hey %s'`# comment`|
cat <<<'there'
hey there
Reacted by Mark Wilkinson, Andrew Hlynskyi and milahu
changed the title [-]Comments inside one-line backtick command expansions are not parsed properly -> `\`# comment\``[/-][+]Comments inside one-line backtick command expansions are not parsed properly -> `# comment`[/+]on Nov 30, 2021
changed the title [-]Comments inside one-line backtick command expansions are not parsed properly -> `# comment`[/-][+]Comments inside one-line backtick command expansions are not parsed properly -> \`# comment\`[/+]on Nov 30, 2021
changed the title [-]Comments inside one-line backtick command expansions are not parsed properly -> \`# comment\`[/-][+]Comments inside one-line backtick command expansions are not parsed properly -> `# comment`[/+]on Nov 30, 2021
Without above upstream feature this issue requires to handle comment nodes in external scanner what will make this parser very inefficient because external scanner would be triggered on every terminal symbol position.
But looking on the current output:
I came up with an idea that maybe it's possible to handle only a part of comment after the # symbol in the external scanner, this would be pretty effective, but define node comment as the next so it wouldn't have any dangling nodes:
Activity
[-]Comments inside one-line backtick command expansions are not parsed properly -> `\`# comment\``[/-][+]Comments inside one-line backtick command expansions are not parsed properly -> `# comment`[/+][-]Comments inside one-line backtick command expansions are not parsed properly -> `# comment`[/-][+]Comments inside one-line backtick command expansions are not parsed properly -> \`# comment\`[/+][-]Comments inside one-line backtick command expansions are not parsed properly -> \`# comment\`[/-][+]Comments inside one-line backtick command expansions are not parsed properly -> `# comment`[/+]ahlinc commentedon Aug 27, 2023
Without above upstream feature this issue requires to handle
commentnodes in external scanner what will make this parser very inefficient because external scanner would be triggered on every terminal symbol position.But looking on the current output:
I came up with an idea that maybe it's possible to handle only a part of comment after the
#symbol in the external scanner, this would be pretty effective, but define node comment as the next so it wouldn't have any dangling nodes:ahlinc commentedon Aug 27, 2023
The second case works fine:

The third case also has an issue:

cf view: end a shell comment inside backticks at the closing backtick
cf view: end a shell comment inside backticks at the closing backtick (…