You are not logged in.
Pages: 1
Vim is wrongly highlighting the closing parenthesis in my shell scripting files.
In other words, it looks like the syntax is wrong (maybe it is).
A picture would illustrate better.
http://imageshack.us/photo/my-images/56 … error.png/
I only have the default sh.vim that comes with gvim 7.3 default
package in arch. Nothing in ~/.vim/syntax or ~/.vim/after/syntax.
Could someone verify if the same happens in your systems. The system
is fully up to date.
Thanks in advance.
Last edited by FernandoBasso (2011-12-20 19:57:39)
There is a difference between knowing the path and walking the path.
Offline
Can't reproduce.
Edit: Spoke too soon, I CAN reproduce it.
If I place the cursor on either parenthesis, the other one will light up, so paren matching works. Weird.
Retyped for other users' convenience:
#!/usr/bin/env bash
if (a); then
# do sth
fi
The red highlighting is present with
#!/bin/bash
shebang too.
Edit 2: Is '(a)' a proper syntax? Changing it to '$(a)' makes things OK.
Last edited by karol (2011-12-20 20:22:46)
Offline
Edit 2: Is '(a)' a proper syntax? Changing it to '$(a)' makes things OK.
Exactly my thoughts.
$ cat t
#! /bin/bash
if (a); do
done
$ t
./t: line 3: syntax error near unexpected token `do'
./t: line 3: `if (a); do'
Try to reproduce the problem with a script that is actually meant to do something, even if it's only something silly like echoing "Hello World" conditional on existence of the "/" directory.
With the problem as it stands, you might as well ask: why doesn't my toaster levitate when I spit Satanic incantations at it, is that a bug in my toaster?
Last edited by /dev/zero (2011-12-20 20:41:15)
Offline
Are you using the sh syntax file?
It can complain on working (complex) scripts.
Try a bash syntax file.
Offline
@/dev/zero
The problem is you used 'do' instead of 'then'.
I get
./script: line 3: a: command not found
#!/usr/bin/env bash
if (a); then
echo foo
fi
When I change it to
#!/usr/bin/env bash
if (true); then
echo foo
fi
I get
[karol@black ~]$ ./script
foo
but the red "error" is still present.
Last edited by karol (2011-12-20 21:03:11)
Offline
@/dev/zero
The problem is you used 'do' instead of 'then'.
lol, so I did :-)
<facepalm />
When I change it to
#!/usr/bin/env bash
if (true); then
echo foo
fiI get
[karol@black ~]$ ./script
foobut the red "error" is still present.
Hmm, that is interesting.
I only get this on my Arch version of vim. The problem is not there on my Debian machine at home or my Ubuntu machine at work.
On each machine, I run:
vim --version | head -1
and obtain the following results:
(Debian)
VIM - Vi IMproved 7.2 (2008 Aug 9, compiled Jul 12 2010 02:31:36)
(Ubuntu)
VIM - Vi IMproved 7.2 (2008 Aug 9, compiled Apr 16 2010 12:40:58)
(Arch)
VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Nov 27 2011 23:39:46)
Last edited by /dev/zero (2011-12-20 21:13:21)
Offline
I've noticed various syntax coloring errors in bash scripts lately.
One of the main ones is that the closing parenthesis of an array is highlighted red, e.g.:
SUBRANGE=(${RANGE[@]})
Another consistent problem is the coloring of file descriptors.
In my first function, the string >&2 is colored completely yellow, but in subsequent functions the same string has a magenta 2.
Furthermore, some string redirects are colored wrong, the final tac being off-colored, e.g.:
if $(grep -q "[^[:digit:]:-]" <<< "$1")
There are often errors in quote delimiting too, e.g. after the following line, the entire file is colored as if it is a string literal:
if $(amixer | grep -A 4 \'$SDEVICE\' | awk {'print $6'} | grep -q "\[off\]")
Also, process substitution looks funny in that the tic is a different color than the parentheses, though that's not specifically incorrect.
I guess the moral of the story is I should try to fix this.
Offline
I only get this on my Arch version of vim. The problem is not there on my Debian machine at home or my Ubuntu machine at work.
On each machine, I run:
vim --version | head -1
and obtain the following results:
(Debian)VIM - Vi IMproved 7.2 (2008 Aug 9, compiled Jul 12 2010 02:31:36)
(Ubuntu)
VIM - Vi IMproved 7.2 (2008 Aug 9, compiled Apr 16 2010 12:40:58)
(Arch)
VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Nov 27 2011 23:39:46)
I have (backup) version of sh.vim (dated back to April 12, 2010) and if I drop that file in ~/.vim/syntax/ and use it instead of the sh.vim version (August 16, 2011) that cames with the default (g)vim 7.3 package in arch, then I don't have that problem with the closing parenthesis being highlighted red.
Last edited by FernandoBasso (2011-12-22 09:05:38)
There is a difference between knowing the path and walking the path.
Offline
I've noticed various syntax coloring errors in bash scripts lately.
One of the main ones is that the closing parenthesis of an array is highlighted red, e.g.:SUBRANGE=(${RANGE[@]})
Another consistent problem is the coloring of file descriptors.
In my first function, the string >&2 is colored completely yellow, but in subsequent functions the same string has a magenta 2.Furthermore, some string redirects are colored wrong, the final tac being off-colored, e.g.:
if $(grep -q "[^[:digit:]:-]" <<< "$1")
There are often errors in quote delimiting too, e.g. after the following line, the entire file is colored as if it is a string literal:
if $(amixer | grep -A 4 \'$SDEVICE\' | awk {'print $6'} | grep -q "\[off\]")
Also, process substitution looks funny in that the tic is a different color than the parentheses, though that's not specifically incorrect.
I guess the moral of the story is I should try to fix this.
These all work if you use a bash syntax file instead of sh.
Offline
These all work if you use a bash syntax file instead of sh.
If I set sytax to bash I get no colors - no syntax at all. I can only set syntax to bash if I have my old backup file (sh.vim, 2010) in ~/.vim/syntax, and it must be renamed to bash.vim. Without that I simply don't have a bash filetype.
Perhaps you have a bash.vim somewhere in your vim's path.
Even with the new version of sh.vim that is bundled with (g)vim 7.3 arch package, if I drop it in ~/.vim/syntax/ but rename to bash.vim, setting filetype or syntax to bash I do get colors, but the red highlight in the closing parenthesis persist.
There is a difference between knowing the path and walking the path.
Offline
Some of the bash syntax highlighting errors can be eliminated by:
:let g:is_bash=1
You can see the help on this with :help ft-bash-syntax.
But it doesn't always work, such as in the example of the opening post.
This silver ladybug at line 28...
Offline
egan wrote:I've noticed various syntax coloring errors in bash scripts lately.
One of the main ones is that the closing parenthesis of an array is highlighted red, e.g.:SUBRANGE=(${RANGE[@]})
Another consistent problem is the coloring of file descriptors.
In my first function, the string >&2 is colored completely yellow, but in subsequent functions the same string has a magenta 2.Furthermore, some string redirects are colored wrong, the final tac being off-colored, e.g.:
if $(grep -q "[^[:digit:]:-]" <<< "$1")
There are often errors in quote delimiting too, e.g. after the following line, the entire file is colored as if it is a string literal:
if $(amixer | grep -A 4 \'$SDEVICE\' | awk {'print $6'} | grep -q "\[off\]")
Also, process substitution looks funny in that the tic is a different color than the parentheses, though that's not specifically incorrect.
I guess the moral of the story is I should try to fix this.
These all work if you use a bash syntax file instead of sh.
I have
let g:is_bash=1
in my vimrc already.
Offline
There's a bash.vim you can find here: http://www.panix.com/~elflord/vim/syntax/
Don't know if it's better, though.
This silver ladybug at line 28...
Offline
No, there really was a bug introduced in some version of vim shortly after 7.3.294. I think it exists as early as 7.3.322.
v7.3.294
v7.3.381
My colorscheme doesn't make it incredibly obvious, but note the different colored closing paren on the array increments. This stands out like a sore thumb in some other colorschemes (e.g. dante gives it an annoying red background because it's labelled an error). Backporting the old syntax file fixes this. This only seems to affect parenthesis inside of functions.
v7.3.381 (same file, but global scope)
Oddly, backporting the old syntax file still shows the same difference in color outside of a function, but it's not labelled an error anymore.
Offline
So, this is getting a bit necroish of me. I thought people interested in this thread would like to know about this which I just came across:
vim syntax bug
To summarise, Charles E Cambell Jr is the maintainer of the *sh syntax for vim. He explains that this is kind of a "won't fix" because it would make the syntax file way too large; for anyone who considers this a problem, he offers a work-around - add this to your .vimrc:
let g:vimsyn_noerror= 1
Offline
So, this is getting a bit necroish of me. I thought people interested in this thread would like to know about this which I just came across:
vim syntax bugTo summarise, Charles E Cambell Jr is the maintainer of the *sh syntax for vim. He explains that this is kind of a "won't fix" because it would make the syntax file way too large; for anyone who considers this a problem, he offers a work-around - add this to your .vimrc:
let g:vimsyn_noerror= 1
Good to know. Thanks a bunch.
There is a difference between knowing the path and walking the path.
Offline
So are the old syntax files much bigger? Or do they lack some functionality enjoyed by the new ones?
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
Pages: 1