Not entirely sure of the feature overlap, but this seems to reinvent grcat and its frontend, grc [1], a little bit.
Grcat lets you configure commands with colour regexps. Then you just prefix the command with "grc", and it will colorize the output according the rules. It's useful to alias commands this way:
$ alias make="grc make"
colout seems most useful when you are want to highlight arbitrary patterns independent of the command, eg. "tail some.log | colout ...".
Indeed. Having to build configuration file for each command was a pain in the ass. Colout is better integrated in my shell workflow and shows that config files are not mandatory (but colout themes do just the same).
Plus, colout have a tons of additional features (256-colors mode, colormaps, etc.).
Really? grcat/grc's configs are very simple. For example, this is the config for colorizing diffs:
regexp=^\+(.*$)
colours=bold green
count=more
=======
regexp=^\-(--.+$|[^\-].*$|$)
colours=bold red
count=more
========
regexp=^\>([^\>].*|$)
colours=bold green
count=more
=======
regexp=^\<([^\<].*|$)
colours=bold red
count=more
=======
regexp=^@@ .* @@$
colours=magenta
count=more
I agree that colout works better for ad-hoc stuff.
You should consider inverting the way it's invoked, though, to be more like grc, otherwise you can't reliably use colout in an alias (as pointed out elsewhere in this thread).
alias ls="ls -lph1 --color=always"
function ls {
/bin/ls $@ | colout [regex] colours
}
This will pass all arguments after "ls" to the /bin/ls command. This also means you can keep your existing aliases clean and tidy for common params.
Remember to use the full path (or /usr/bin/env maybe) so that you don't create a recursive call to your function ;)
This doesn't deal with the situation of being unable to get the return value of the original command, but depending on your needs, this may not be an issue.
Just to be clear, in case the post's headline misleads you, there's nothing OS X specific about colout - it'll work just as happily on Linux. The documentation even points to an PPA from where you can install an Ubuntu package.
I can see a bunch of ways I'll make use of this. The first one I attempted to work on involved trying to color scale the use% in the output of a "df -h".
Alas it didn't work as I expected it:
$ df -h | colout --scale 0,100 "([0-9]*)%" scale
ValueError: could not convert string to float:
However if I grep out just the /dev/sda line it does what I expected:
You use the "zero or more" * operator, which will match empty strings in front of the "%". But an empty string cannot be converted to a float. Just use the "at least one" operator: +. Also, the scale is 0,100 by default, you can omit it.
I really like the idea of alternating the color of lines of output, although I might use something a bit less bold. Is there an easy way to have command piped through this in bash?
one problem of the 'alias yourcmd to yourcmd | colorize' is dealing with preserving the return code from the actual command, rather than the last in the pipeline.
It can be done with things liek $PIPESTATUS, but some sort of wrapper/function to do it would be nice.
There is some incompatibility, like the gettext module in the g++ theme, the way themes are imported, unicode support, the print statement…
But maybe it's still possible to write a code that work on both versions?
I see. As a quick fix, I tried to call python 2.6 from the colout script, but that failed because importlib exists only in python3. I don't know how to make it work on both versions, I'm afraid.
The background image of this site causes a weird strobing effect on the screen of my MacBook Pro 6,2. Really odd.
When I drag it over to the cinema display it looks fine.
Noone else here in the office can see it, both those with good vision and those who are technically blind. Maybe I have special powers. Or a brain tumor.
This might be a dumb question: are there shells that have a HTML-based front and passes commands into the background? Seems like something like that would be far more flexible than this – which feels like a Jenga tower of hacks.
TermKit[1] was built in this way a few years ago. It was novel at the time and the demo[2] seemed promising, but looks like it hasn't been updated in ~2 years now.
I like the idea of colored permissions. Even if your aren't looking specifically at them an ls -latest would draw your attention if something we're set insecurely.
That's because the log was already colored (the word "fail" in red). As colout tries to color the whole line, the previous end escape character is interpreted by the terminal before the last one :
<red>* This is a colored line [<red>fail<end>]</end>
(You can use the `--debug` switch of colout to get hints about such problems).
It's not really a replication, as colout just _USE_ the pygments library. Colout just add the possibility to color code that is located inside a text that should not be colored, which pygmentize cannot do:
colout -a -s Python monokai < code.py # just like pygmentize
colout "^(:*)'(:*)'(:*)$" blue,python,blue < code.py # just the code 'inside quotes', not the rest of the line
Grcat lets you configure commands with colour regexps. Then you just prefix the command with "grc", and it will colorize the output according the rules. It's useful to alias commands this way:
colout seems most useful when you are want to highlight arbitrary patterns independent of the command, eg. "tail some.log | colout ...".[1] http://kassiopeia.juls.savba.sk/~garabik/software/grc/README...