syntax highlight of sqlite3 script using bash here document

557 views
Skip to first unread message

Peng Yu

unread,
Jul 4, 2010, 5:51:20 PM7/4/10
to vim_use
Due to the fact that sqlite3 can not directly process a file using
shebang, I have to use the here document from bash for sqlite3 script.
But the syntax highlight is not correct. Does anybody have any fix to
the vim default for this kind of sqlite3 script embedded in bash here
document? Note that the complication is that environment variable can
be used in the here document, which can be enclosed in for loop.

$ cat main.sql
#!/usr/bin/env bash

rm -rf main.db
sqlite3 main.db <<EOF

.mode column
.headers on
.echo on
create table test (id integer primary key, value text);
insert into test (value) values('eenie');
insert into test (value) values('meenie');
insert into test (value) values('miny');
insert into test (value) values('mo');
insert into test (value) values('$SOME_ENV_VAR');

select * from test;

EOF

Zoran Zaric

unread,
Jul 4, 2010, 6:02:22 PM7/4/10
to vim...@googlegroups.com
I hope I got your question right. You can force vim to use the
highlighting for a special filetype by setting the filetype for the
current buffer.

:set filetype=sql

did the correct highlighting of the sql-code for me.

I hope this helps.

Peng Yu schrieb:

Peng Yu

unread,
Jul 5, 2010, 11:12:09 AM7/5/10
to vim_use
No. You misunderstood me. I think that the vim can recognized the file
type by the suffix of the filename. There is no need to ":set
filetype=sql" explicitly.

But the default syntax highlight facility in vim doesn't reliably
syntax highlight SQL code embedded in a bash script. In the following
example, the SQL code after "*.txt" is not recognized correctly.


#!/usr/bin/env bash

rm -f main.db
sqlite3 main.db <<EOF
create table test (ID1 integer, ID2 integer);
EOF

for f in xxx/*.txt;
do

geneid=`basename $f .txt`
echo $id

sqlite3 main.db <<EOF
create temp table dummy(value integer);
.import xxx/$id.txt dummy
insert into test (ID1, ID2) select '$id', value from dummy;
EOF

done

Benjamin R. Haskell

unread,
Jul 5, 2010, 1:27:32 PM7/5/10
to vim_use
On Mon, 5 Jul 2010, Peng Yu wrote:

> No. You misunderstood me. I think that the vim can recognized the file
> type by the suffix of the filename. There is no need to ":set
> filetype=sql" explicitly.
>
> But the default syntax highlight facility in vim doesn't reliably
> syntax highlight SQL code embedded in a bash script. In the following
> example, the SQL code after "*.txt" is not recognized correctly.

The syntax highlighting for PHP handles highlighting other languages
within heredocs. Perhaps you can find a solution somewhere in there.

I believe it 'detects' the language via the heredoc label, though, so
you might need to use <<SQL
SQL
instead of <<EOF
EOF

See also:

:help :syn-include

--
Best,
Ben

Charles Campbell

unread,
Jul 6, 2010, 3:51:16 PM7/6/10
to vim...@googlegroups.com

As I see it, the script is being highlighted correctly from sh's
viewpoint, as a heredoc is essentially just a long string.

What you appear to want is for the sh syntax script to recognize sqlite3
in the command and highlight the following heredoc using that other
syntax. As Ben H pointed out, it is possible to use the syn-include
approach to get what you want. I suggest writing a bit of extra syntax
handling for this purpose and put it in your .vim/after/syntax/sh.vim
file. Such a region would be recognized at the outset with sqlite3,
etc. However, I don't think sh.vim is the place to try to recognize
every possible language that heredoc strings might be using.

HTH,
Chip Campbell

Benjamin R. Haskell

unread,
Jul 6, 2010, 4:55:24 PM7/6/10
to vim...@googlegroups.com

Yep. That's what I was suggesting. And I agree that it shouldn't be in
the general 'syntax/sh.vim'. The following worksforme:

==> ~/.vim/after/syntax/sh.vim <==
unlet b:current_syntax
syntax include @sql syntax/sql.vim
syn region shHereDoc matchgroup=shRedir start=/<<\s*\\\=\z(\S*\)/ end=/^\z1\s*$/ contains=@shDblQuoteList,@sql
==================================

I got the pattern for the last line by looking at the patterns already
in the 'sh' filetype (With a 'sh' file open, run :syn). If it doesn't
work right for how you style your heredocs, you might want to try a
different one. (Not sure what the subtleties are that the many similar
matches are trying to capture, other than the contains-quoted-items
dichotomy.) You should also add the 'fold' flag if you use
g:sh_fold_enabled.

--
Best,
Ben

Peng Yu

unread,
Jul 6, 2010, 9:35:49 PM7/6/10
to vim_use
Note that I'm using the suffix .sql rather .sh, as I think that bash
is just a wrapper, the main stuff is in sql. The about tips help only
if a .sh suffix is used. Could you please take a look for the case
where .sql suffix is used? Thank you!

Benjamin R. Haskell

unread,
Jul 6, 2010, 11:40:53 PM7/6/10
to vim_use
On Tue, 6 Jul 2010, Peng Yu wrote:
> On Jul 6, 3:55 pm, "Benjamin R. Haskell" wrote:
> > [...]

> > The following worksforme:
> >
> > ==> ~/.vim/after/syntax/sh.vim <==
> > unlet b:current_syntax
> > syntax include @sql syntax/sql.vim
> > syn region shHereDoc matchgroup=shRedir start=/<<\s*\\\=\z(\S*\)/ end=/^\z1\s*$/ contains=@shDblQuoteList,@sql
> > ==================================
> >
> > [...]

>
> Note that I'm using the suffix .sql rather .sh, as I think that bash
> is just a wrapper, the main stuff is in sql. The about tips help only
> if a .sh suffix is used. Could you please take a look for the case
> where .sql suffix is used? Thank you!

Regardless of what the main stuff is, it's still wrapped as a bash
script. I'd just use the .sh or .bash suffix, since that's what the
file is.

But, Vim will also let you call an apple an orange. In your vimrc:

aug FileTypeOverride
au!
au BufRead *.sql if -1 != match(getline(1),'^#!.*sh\>') | set ft=sh | endif
aug END

Note the use of 'set ft' rather than 'setf', which forces the filetype
to 'sh', even if it gets set to 'sql' before this autocmd is run.

The '^#!.*sh\>' pattern matches a shebang line containing a shell-like
name. e.g. #!/bin/bash, #!/bin/sh, #!/usr/local/bin/ash

--
Best,
Ben

Reply all
Reply to author
Forward
0 new messages