GNOME Bugzilla – Bug 521195
'sh' syntax highlighting actually for bash, and uses syntax invalid for Bourne shell
Last modified: 2008-08-02 23:11:38 UTC
The bug has been opened on https://bugs.launchpad.net/bugs/196785 "Gedit's syntax highlighting for 'sh' actually is for bash. Functions and arrays are not valid Bourne shell, and scripts starting with '/bin/sh' which use these will fail on: * Bourne shell (/bin/sh) * Bash version 3 and later on many systems, depending on the compile time options of bash. If bash version 3's default POSIX compatibility has been disabled, the behavior may be demonstrated using 'bash --posix file.sh' Simple fix: mark the syntax highlighting currently labeled as 'sh' as being 'bash'. Extended fix: include an actual Bourne shell syntax highlighting mode, which marks invalid bourne shell syntax in red. http://launchpadlibrarian.net/12344708/sh_arrays.sh sh_arrays.sh (1.8 KiB, text/x-sh) Here's a cheesy example from Advanced Bash Scripting Guide Gedit hightlights both the same even though the array syntax is illegal in normal Bourne shell (sh) programming. Here are the results: tgalati4@minty5:~/Projects$ ./bash_arrays.sh area[11] = 23 area[13] = 37 Contents of area[51] are UFOs. area[43] = (area[43] unassigned) area[5] = area[11] + area[13] area[5] = 60 expr: non-numeric argument area[6] = area[11] + area[51] area[6] = area2[0] = zero area2[1] = one area3[17] = seventeen area3[24] = twenty-four tgalati4@minty5:~/Projects$ ./sh_arrays.sh ./sh_arrays.sh: 4: area[11]=23: not found ./sh_arrays.sh: 5: area[13]=37: not found ./sh_arrays.sh: 6: area[51]=UFOs: not found area[11] = ./sh_arrays.sh: 17: Syntax error: Bad substitution http://launchpadlibrarian.net/12344712/bash_arrays.sh bash_arrays.sh (1.8 KiB, text/x-sh) bash_arrays.sh attached."
Here's what I said in ubuntu bug: We are cheating here, true, we say "sh" when it's really "bash". But I don't think it's a real problem, so I tend to close the upstream bug with WONTFIX. It's similar to highlighting TRUE and FALSE in C code - these aren't standard identifiers, yet they are common enough and we highlight them. "Simple fix" above is not acceptable, there must be a language with id "sh". "Extended fix" is possible but wrong. If there is sh.lang, then it will be used for all sh-like scripts, including bash scripts (at least with our advanced unix technologies). All in all, it's a small issue without a small fix.