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
[bash] commands after HEREDOC delimiter are highlighted like the HEREDOC #35
Not seeing this issue in TextMate, the regex here looked reasonably straightforward so nothing jumps out as being the issue. My first suspicion is a different in regex engine syntax but I know basically nothing about how vsCode is implemented language-wise.
The code as pasted doesn’t highlight anything as a heredoc. The grammar doesn’t allow whitespace in between << and the heredoc token, although it should. I believe we’ve recently fixed this for generic redirections but not for heredocs.
With heredoc highlighting fixed (or when removing the space before EOD), the remainder of the line starting the heredoc is also treated as a heredoc, although it shouldn’t. Fixing this is more involved and I’m still thinking about how best to do this.
A short sketch of what I’m thinking:
Our current rules describe a heredoc as beginning and ending at the token.
Instead, the beginning token could open a scope with two rules:
begin: lookbehind at the heredoc operator and token, end: newline, include: $self and possibly a rule matching backslash-escaped newlines (to prevent those from ending this scope)
begin: lookbehind at newline (or lookahead at anything), end: lookahead at heredoc token
The second rule would provide the actual heredoc scope.
I don’t think child rules can access their parents’ matches, so the actual heredoc token wouldn’t be available there. We could try to treat anything like possible heredoc tokens, relying on the fact that if the parent’s end fails the second rule’s begin would match.
This problem also seems to be present in the Ruby bundle.
There is also the possibility of matching the (start) heredoc token and then capture the rest of the line, and for the captures part of the rule, include $self, this would avoid the nested scope, but it would not be possible to handle escaped newlines after the heredoc token.
Update to myself. The quotes didn't work, they actually broke variable expansion. Randomly though I discovered that you need a space after EOT. Bash doesn't care, but VSCode does. To be fair, many pages do show the spaces: https://linuxize.com/post/bash-heredoc/ ,so even though they aren't needed by bash, I'm not sure this is a bug.
This may be well known by others, but I'm guessing this bug wouldn't be here if everyone knew.
Activity
infininight commentedon Jan 14, 2017
Not seeing this issue in TextMate, the regex here looked reasonably straightforward so nothing jumps out as being the issue. My first suspicion is a different in regex engine syntax but I know basically nothing about how vsCode is implemented language-wise.
mkhl commentedon Jan 14, 2017
I believe that there are two issues here:
The code as pasted doesn’t highlight anything as a heredoc. The grammar doesn’t allow whitespace in between
<<and the heredoc token, although it should. I believe we’ve recently fixed this for generic redirections but not for heredocs.With heredoc highlighting fixed (or when removing the space before
EOD), the remainder of the line starting the heredoc is also treated as a heredoc, although it shouldn’t. Fixing this is more involved and I’m still thinking about how best to do this.A short sketch of what I’m thinking:
Our current rules describe a heredoc as beginning and ending at the token.
Instead, the beginning token could open a scope with two rules:
The second rule would provide the actual heredoc scope.
I don’t think child rules can access their parents’ matches, so the actual heredoc token wouldn’t be available there. We could try to treat anything like possible heredoc tokens, relying on the fact that if the parent’s end fails the second rule’s begin would match.
This problem also seems to be present in the Ruby bundle.
sorbits commentedon Jan 14, 2017
There is also the possibility of matching the (start) heredoc token and then capture the rest of the line, and for the captures part of the rule, include
$self, this would avoid the nested scope, but it would not be possible to handle escaped newlines after the heredoc token.dexwerx commentedon Mar 2, 2018
annual bump!
IvanRoman commentedon Sep 18, 2018
I was wondering if there is any update on this. I can see this issue on Ubuntu 18.04.1 with VS Code v. 1.27.2
NorseGaud commentedon Jun 18, 2019
2019 bump!!! This is extremely annoying.
On Mojave.
Mist-Hunter commentedon Aug 4, 2020
Same problem. 2020 bump, just started to get on the vscode bus, but I use heredoc's allot..
Mist-Hunter commentedon Aug 21, 2020
FYI, quoting EOT seems to fix this. Example.
No quotes, not working

Quotes (double below, but single also works) working. Using double due presence of variables

Mist-Hunter commentedon Sep 13, 2020
Update to myself. The quotes didn't work, they actually broke variable expansion. Randomly though I discovered that you need a space after EOT. Bash doesn't care, but VSCode does. To be fair, many pages do show the spaces: https://linuxize.com/post/bash-heredoc/ ,so even though they aren't needed by bash, I'm not sure this is a bug.
This may be well known by others, but I'm guessing this bug wouldn't be here if everyone knew.
cat < makes VS Code sad
cat < gets highlighted properly and works!
jannek-aalto commentedon Nov 10, 2020
Still broken in vscode 1.49.2 for ksh space-trimming heredoc syntax '<<#word'.