Incorrect syntax highlight of things like '\r' within EOF block in bash script

343 views
Skip to first unread message

Peng Yu

unread,
Jul 17, 2013, 4:02:02 PM7/17/13
to vim_use
Hi,

vim can not syntax highlight the following script correctly. Does
anybody know a better highlight plugin that can correct highlight it?
Thanks.

~/linux/test/latex/tex/bin$ cat main.sh
#!/usr/bin/env bash

tex <<EOF
\relax
Hello?
\end
EOF

--
Regards,
Peng

Adnan Zafar

unread,
Jul 17, 2013, 4:09:28 PM7/17/13
to vim...@googlegroups.com
Inside of heredocs, bash (and other shells) can do certain expansions
and substutions, so the Vim syntax highlights for those. However if
the delimiter word (here EOF) is quoted in some way, like \EOF then
those expansions and substitutions are disabled, and Vim's syntax
adjusts accordingly.

In short either escape backslashes inside the heredoc or simply use

tex << \EOF
\relax
Hello?
\end
EOF

--Adnan

Peng Yu

unread,
Jul 17, 2013, 4:22:50 PM7/17/13
to vim...@googlegroups.com
The following is the document from bash. I don't see the usage of
\EOF. Do you know where it is documented? I tried both \EOF and EOF,
both of them generate the same dvi file. So it seems \r and \e are
take literally by tex (i.e., a backslash and 'r', a backslash and
'e'). Is it so?

Here Documents
This type of redirection instructs the shell to read input from the
current source until a line containing only delimiter (with no trailing
blanks) is seen. All of the lines read up to that point are then used
as the standard input for a command.

The format of here-documents is:

<<[-]word
here-document
delimiter

No parameter expansion, command substitution, arithmetic expansion, or
pathname expansion is performed on word. If any characters in word are
quoted, the delimiter is the result of quote removal on word, and the
lines in the here-document are not expanded. If word is unquoted, all
lines of the here-document are subjected to parameter expansion, com-
mand substitution, and arithmetic expansion. In the latter case, the
character sequence \<newline> is ignored, and \ must be used to quote
the characters \, $, and `.

If the redirection operator is <<-, then all leading tab characters are
stripped from input lines and the line containing delimiter. This
allows here-documents within shell scripts to be indented in a natural
fashion.


--
Regards,
Peng

Gary Johnson

unread,
Jul 17, 2013, 4:23:31 PM7/17/13
to vim...@googlegroups.com
On 2013-07-17, Adnan Zafar wrote:
Except that bash does not expand \r or \e in Peng's context.


$ od -bc <<EOF
\relax
Hello?
\end
EOF

0000000 134 162 145 154 141 170 012 110 145 154 154 157 077 012 134 145
\ r e l a x \n H e l l o ? \n \ e
0000020 156 144 012
n d \n
0000023


Regards,
Gary

Adnan Zafar

unread,
Jul 17, 2013, 5:04:52 PM7/17/13
to vim...@googlegroups.com
The use of \EOF is mentioned in the following paragraph, specifically
"If any characters in word are quoted". Although the docs says that
backslashes must be escaped if the word is unquoted, I guess bash
leaves them alone in some circumstances The way Vim's syntax works
will cause the escape sequences to be highlighted unless you quote a
character in the word though, and Vim's syntax seems to only recognize
when the first character is quoted.

> No parameter expansion, command substitution, arithmetic expansion, or
> pathname expansion is performed on word. If any characters in word are
> quoted, the delimiter is the result of quote removal on word, and the
> lines in the here-document are not expanded. If word is unquoted, all
> lines of the here-document are subjected to parameter expansion, com-
> mand substitution, and arithmetic expansion. In the latter case, the
> character sequence \<newline> is ignored, and \ must be used to quote
> the characters \, $, and `.

--Adnan

John Little

unread,
Jul 18, 2013, 3:23:08 AM7/18/13
to vim...@googlegroups.com
On Thursday, 18 July 2013 08:02:02 UTC+12, Peng Yu wrote:
>
> vim can not syntax highlight the following script correctly...

Are you asking how to apply tex syntax highlighting to a script embedded in a bash script? Perhaps:

http://vim.wikia.com/wiki/Different_syntax_highlighting_within_regions_of_a_file

can help, or, more likely, the TeX and LaTex people will help; I suggest putting "TeX" in the subject would have been a good idea.

Regards, John Little

Charles E Campbell

unread,
Jul 18, 2013, 9:05:26 AM7/18/13
to vim...@googlegroups.com
Peng Yu wrote:
> Hi,
>
> vim can not syntax highlight the following script correctly. Does
> anybody know a better highlight plugin that can correct highlight it?
>
May I suggest that you..

Read :help sh-embed

Modify the example to do LaTeX:

" TEX Embedding: {{{1
" ==============
" Shamelessly ripped from aspperl.vim by Aaron Hope.
if exists("b:current_syntax")
unlet b:current_syntax
endif
syn include @TEXScript syntax/tex.vim
syn region TEXScriptCode matchgroup=TEXCommand start=+[=\\]\@<!'+
skip=+\\'+ end=+'+ contains=@TEXScript contained
syn region TEXScriptEmbedded matchgroup=TEXCommand start=+\<tex\>+
skip=+\\$+ end=+[=\\]\@<!'+me=e-1 contains=@shIdList,@shExprList2
nextgroup=TEXScriptCode
syn cluster shCommandSubList add=TEXScriptEmbedded
hi def link TEXCommand Type
syn region shHereDoc matchgroup=shRedir20 start="<<\s*\\\=\z([^
\t|]*\)" matchgroup=shRedir20 end="^\z1\s*$"
contains=@shDblQuoteList,@TEXScript

I identified which shHereDoc to recognize (ie. the one with shRedir20)
by using :HLT! and moving the cursor into the block. :HLT is provided
courtesy of my hilinks.vim plugin, available at my website as:
http://www.drchip.org/astronaut/vim/index.html#HILINKS

Regards,
Chip Campbell

Gary Johnson

unread,
Jul 18, 2013, 10:49:15 AM7/18/13
to vim...@googlegroups.com
On 2013-07-18, John Little wrote:
> On Thursday, 18 July 2013 08:02:02 UTC+12, Peng Yu wrote:
> >
> > vim can not syntax highlight the following script correctly...
>
> Are you asking how to apply tex syntax highlighting to a script
> embedded in a bash script?

That's not the problem, as I understand it. The problem is that Vim
incorrectly highlights the "\r" and the "\e" differently than the
rest of the here document, suggesting that bash treats them
differently, perhaps as carriage-return and escape, when in fact
bash does not treat those pairs differently than the individual
characters they comprise.

Regards,
Gary

Reply all
Reply to author
Forward
0 new messages