styling more commands (and basic parameter patterns) #7

tbates opened this Issue Nov 27, 2011 · 6 comments


None yet
3 participants

tbates commented Nov 27, 2011

shellscript.tmbundle currently doesn't highlight parameters and parameter value pairs, and has a minimal set of commands (like ls)

It would be great if shell could style more commands and their parameters.

One suggestion would be the commands that are included with lion: svn, git etc. with their parameters properly highlighted.

Are there automatable way to discover this/integrate with man etc?


mkhl commented Feb 25, 2012

First of all, patches are of course always welcome. :-)

That said, I'm not a big fan of this, and I'm having a hard time explaining
why, but let me try anyway.

The language grammar from the shell script bundle does not highlight options
and option arguments because they are not part of the grammar of the shell
language. It does not highlight any external commands at all (not even ls(1))
because they are not part of the shell language. It does highlight reserved
words (like if and function) and builtin commands (like cd and exit),
all of which are defined in the bash(1) man page (sections RESERVED WORDS and

In the case of commands, I don't even see that much of a benefit in
highlighting commands that belong to a certain set, although that might be an
artifact of my current situation (most scripts I write these days are run on
some linux server). I think it would be nicer to highlight which word in the
current pipeline is actually the command, but that isn't easy even and could
make our language grammar considerably more complex.

The situation for options is even worse because every command is responsible
for parsing its arguments, there are multiple competing standards (POSIX
defines short options with a dash; X adds short options with a plus; BSD adds
long options with a single dash, GNU adds long options with double dashes; some
of them support options after the arguments, others don't) and a magnitude of
incompatible option parsing libraries implementing subsets of a subset of the
standards or just doing their own thing (like the subcommands popular SCMs
support). The only way I can see to highlight options is to just highlight
every word that starts with a plus or dash. The only way to highlight option
arguments is to highlight the latter part of --option=value words and
ignoring all other forms like --option value or -ovalue. There is
definitely no way to highlight option arguments correctly, because there is no
way to decide which options of which commands take arguments, even ignoring the
facts that it's hard to decide what the current command word is and impossible
to decide what the actual command invoked by that word is going to be.

I prefer my grammars to be less helpful if that saves them from being actively

Are there automatable way to discover this/integrate with man etc?

Sadly, there is not. Man pages are entirely free form and composed of stylistic
as opposed to semantic markup. Not even things like section names are
standardized to help us find options among the text (they actually are, but
with multiple competing standards, none of which the majority of man pages
conform to).

And that is the reason why there are these huge packages of scripts to support
tab completion for shells: To figure out the things you are talking about, in a
few hundred lines of shell script per command. (The git completion file is
over 2700 lines for bash and over 6100 for zsh, but in addition to options
those also know about commands, branches, remotes etc.)

I hope I could convey why I'm reluctant to jump on these additions. And maybe
I'm missing something and it's not as bad as I think, but for now I'm sceptical.


tbates commented Feb 29, 2012

hi Mkhl,

How about highlighting \b([+-]+)([^ ]*)\b and see how people like it?


mkhl commented Mar 5, 2012

Fine with me. I know which of my scripts it'll "break" on and how to disable it. :-)


tbates commented Mar 13, 2012

ok: I'll push something up along those lines.


tbates commented Jul 9, 2013

And a year later...


infininight commented Jul 9, 2013

@tbates Your last comment from last year suggested that you'd open a pull request containing such a change, I don't see any open pull requests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment