Yes this is the idea, but it's not transparent
and hence pretty much useless. To make
it transparent I could do:
1. Make bash write it's prompt (and typed user input)
to tty instead of stderr. This would allow me to do:
exec 2> somewhere
at a prompt which would get all ouput to stderr to
go to somewhere. Why do commands which need
to interact with the user read/write stderr rather than
/dev/tty? Silly in my opinion.
2. Somewhere should probably be another device
(/dev/stderr.colour ?) which could be handled by
a colourize module, which for stderr would just
be to surround data with "\e[31m" ... "\e[0m"
Somewhere could also just be a FIFO with a daemon
listening for data on it and writing it suitably colourized
back to /dev/tty. However this would be asynchronous
to the running commands and probably not the way to
/dev/stdout.colour could also be processed by this
module, and could highlight URLs and user specified
regular expressions etc.
Maybe I should integrate more closely with terminals
and have colourized mode as well as cooked/raw ?
OK I'm rambling now....
Paul Jakma wrote:
>hmmm... didn't you ask for:
Maintained by the ILUG website team. The aim of Linux.ie is to
support and help commercial and private users of Linux in Ireland. You can
display ILUG news in your own webpages, read backend
information to find out how. Networking services kindly provided by HEAnet, server kindly donated by
Dell. Linux is a trademark of Linus Torvalds,
used with permission. No penguins were harmed in the production or maintenance
of this highly praised website. Looking for the
Indian Linux Users' Group? Try here. If you've read all this and aren't a lawyer: you should be!