[FFmpeg-devel] [PATCH] add colours to warnings and errors
Michael Niedermayer
michaelni
Sat Apr 24 23:18:57 CEST 2010
On Sat, Apr 24, 2010 at 03:03:58AM +0200, James Darnley wrote:
> Attached is hopefully the final revision.
> It should not alter the behavior when _WIN32 is not defined at compile time.
> When it is, colour will be printed in:
> - "plain" cmd.exe
> - cygwin and msys cmd.exe terminals when "tty" is not in the CYGWIN
> environment variable
>
> Other terminals in which you might run a native Windows executable
> look like they are SOL. If they get changed so that isatty() returns
> true when you would expect it to then they should start working
> without any change to ffmpeg.
>
> If someone wanted to try and make a hack for isatty() then I suggest
> this as a starting point:
> http://www.cygwin.com/ml/cygwin/2007-03/msg00663.html
> Some state of the stderr pipe might let you find if it is attached to
> a cygwin tty. I tried to recreate that myself but I wasn't very
> successful. I also think that I showed that you can't know whether it
> is rxvt or another program using the pipe, perl or python for example.
> log.c | 69 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 69 insertions(+)
> 7b72f819a31ca8429b43432c8a57be878f1ea3ec colours.diff
> Index: libavutil/log.c
> ===================================================================
> --- libavutil/log.c (revision 22957)
> +++ libavutil/log.c (working copy)
> @@ -24,6 +24,10 @@
> * logging functions
> */
>
> +#ifdef _WIN32
> +#include <windows.h>
> +#include <string.h>
> +#endif
> #include <unistd.h>
> #include <stdlib.h>
> #include "avutil.h"
> @@ -35,9 +39,73 @@
> int av_log_level = AV_LOG_INFO;
>
> static int use_ansi_color=-1;
> +#ifdef _WIN32
> +static int use_win_color=-1;
> +static int16_t attr, attr_orig;
> +static HANDLE con;
> +#endif
>
> +/* FIXME: On Windows isatty() returns true when ANSI color codes won't work.
> +Some hack to detect output to other terminals would be good, fixing the other
> +terminals would be better. One probable exception is when the user has
> +ANSI.SYS loaded but the Windows API should then still work. */
> +
> #undef fprintf
> static void colored_fputs(int color, const char *str){
> +#ifdef _WIN32
these 2 ifdefs can be merged
> + static const int16_t win_color_conv[] = {
> + 0,
> + FOREGROUND_RED,
> + FOREGROUND_GREEN,
> + FOREGROUND_RED |FOREGROUND_GREEN,
> + FOREGROUND_BLUE,
> + FOREGROUND_RED |FOREGROUND_BLUE,
> + FOREGROUND_GREEN|FOREGROUND_BLUE,
> + FOREGROUND_RED |FOREGROUND_GREEN|FOREGROUND_BLUE
> + };
> + if (use_ansi_color<0 || use_win_color<0) {
> + CONSOLE_SCREEN_BUFFER_INFO con_info;
> +
> + use_ansi_color = isatty(2) && getenv("TERM") && !getenv("NO_COLOR")
> + && ( !strncmp(getenv("TERM"), "msys", 4)
> + || !strncmp(getenv("TERM"), "xterm", 5)
> + || !strncmp(getenv("TERM"), "rxvt", 4)
> + //|| !strncmp(getenv("TERM"), "cygwin", 6)
> +/* The CYGWIN environment variable makes this hard for native executables.
> +notty -- programs are directly connected to cmd so the Windows API works
> +tty -- programs are not directly connected so ANSI color codes work
> +The default is notty so leaving "cygwin" excluded doesn't cause problems. */
> + );
> +
> + con = GetStdHandle(STD_ERROR_HANDLE);
> + if (con!=INVALID_HANDLE_VALUE) {
> + GetConsoleScreenBufferInfo(con, &con_info);
> + attr_orig = con_info.wAttributes;
> +
> + attr = (attr_orig&0xF0);
> + attr |= (attr_orig&BACKGROUND_INTENSITY)?0:FOREGROUND_INTENSITY;
> +
> + use_win_color = 1;
> + } else
> + use_win_color = 0;
> + }
> +
> + if ((color&15)==9) {
> + fputs(str, stderr);
> + return;
> + }
> + if (use_ansi_color)
> + fprintf( stderr, "\033[%d;3%dm", color>>4, color&15 );
> + else if (use_win_color)
> + SetConsoleTextAttribute( con, attr | win_color_conv[color&15] );
> +
> + fputs(str, stderr);
> +
> + if (use_ansi_color)
> + fprintf( stderr, "\033[0m" );
> + else if (use_win_color)
> + SetConsoleTextAttribute( con, attr_orig );
> +#else
> if(use_ansi_color<0){
> #if HAVE_ISATTY && !defined(_WIN32)
> use_ansi_color= getenv("TERM") && !getenv("NO_COLOR") && isatty(2);
> @@ -53,6 +121,7 @@
> if(use_ansi_color){
> fprintf(stderr, "\033[0m");
> }
> +#endif
if(use_win_color){
...
}else
#else
{
if(use_ansi_color<0){
#if HAVE_ISATTY && !defined(_WIN32)
use_ansi_color= getenv("TERM") && !getenv("NO_COLOR") && isatty(2);
@@ -53,6 +121,7 @@
if(use_ansi_color){
fprintf(stderr, "\033[0m");
}
}
#endif
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100424/04f589f2/attachment.pgp>
More information about the ffmpeg-devel
mailing list