Emerge by default disables colors when output is piped. This is annoying when piped to pagers (more, less) since it makes impossible to parse long outputs of emerge. qpkg does not have this problem. Issue discussed in forum thread here : http://forums.gentoo.org/viewtopic.php?p=879908#879908 Reproducible: Always Steps to Reproduce: 1. Emerge command [package name] |less 2. 3. Actual Results: The colors in the output of emerge have disappeared (they are in fact disabled because the output is a pipe) Expected Results: Colors should have been kept because output is still on a terminal (because of less) Gentoo Base System version 1.4.3.13 Portage 2.0.50-r1 (default-x86-1.4, gcc-3.3.2, glibc-2.3.2-r9, 2.4.22) ================================================================= System uname: 2.4.22 i686 Celeron (Coppermine) Autoconf: sys-devel/autoconf-2.58-r1 Automake: sys-devel/automake-1.7.7 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O3 -march=pentium3 -funroll-loops -pipe" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-O3 -march=pentium3 -funroll-loops -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="ftp://gentoo.ccccom.com ftp://sunsite.ualberta.ca/pub/unix/Linux/gentoo/ ftp://ftp.isu.edu.tw/pub/Linux/Gentoo ftp://ftp.gtlib.cc.gatech.edu/pub/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X Xaw3d aalib apm avi berkdb crypt cups dga directfb emacs encode foomaticdb gd gdbm gif gnome gpm gstreamer gtk gtk2 gtkhtml imap imlib java joystick jpeg ldap libg++ libwww mad mikmod mmx motif mpeg mule ncurses nls oggvorbis opengl oss pam pcmcia pdflib perl plotutils png python quicktime readline samba scanner sdl slang spell ssl svga tcpd tetex tiff truetype trusted unicode usb x86 xml2 xmms xv zlib"
(In reply to comment #0) > Emerge by default disables colors when output is piped. This is annoying when piped to pagers (more, less) since it makes impossible to parse long outputs of emerge. I would really like to see this resolved by adding a --color option to emerge that forces colored output regardless of pipe/tty status.
I second this feature request. less -R is perfectly capable of displaying colours and colours add visually immediate information to the output of emerge not easily reproduced by other formatting means ...
Is this not very easy to implement? I too really miss this feature.
(In reply to comment #3) > Is this not very easy to implement? I too really miss this feature. It's quite easy, but we're not adding any new features to the 2.1 branch in order to ensure that it is stable in time for the 2006.1 release. As a workaround, you may want to install app-misc/screen and use it's scrollback buffer instead. I always run emerge inside of a screen session so that I can detach/reattach from a plain console or xterm whenever I want.
(In reply to comment #4) > It's quite easy, but we're not adding any new features to the 2.1 branch in > order to ensure that it is stable in time for the 2006.1 release. As a > workaround, you may want to install app-misc/screen and use it's scrollback > buffer instead. I always run emerge inside of a screen session so that I can > detach/reattach from a plain console or xterm whenever I want. Thank you for your reply. Since it is easy I'm just surprised it hasn't been added since this bug is more than 2 years old. What I would really like to do is pipe the output of emerge --pretend into a file from a cron job and including colors. Now I don't know of a way to run an emerge command in a screen session from a cron job.. ;)
Here's a quick little patch that lets you use --color force colors even though stdout is a pipe. === modified file 'bin/emerge' --- bin/emerge +++ bin/emerge @@ -74,7 +74,10 @@ if (not sys.stdout.isatty()) or (portage.settings["NOCOLOR"] in ["yes","true"]): - nocolor() + if "--color" in sys.argv: + sys.argv.remove("--color") + else: + nocolor() def normpath(mystr): if mystr and (mystr[0]=='/'):
(In reply to comment #6) > Here's a quick little patch that lets you use --color force colors even though > stdout is a pipe. Thank you very much. Works too. :)
After upgrading to portage-2.1_rc2-r3 I got this: # emerge --color -vp world !!! Error: --color is an invalid option. So my patch now looks like this: ====================================== diff -Naur portage-2.1_rc2/bin/emerge portage-2.1_rc2-mod/bin/emerge --- portage-2.1_rc2/bin/emerge 2006-05-26 14:11:17.000000000 +0200 +++ portage-2.1_rc2-mod/bin/emerge 2006-05-26 14:12:43.000000000 +0200 @@ -91,9 +91,10 @@ del myvar if (not sys.stdout.isatty()) or (portage.settings["NOCOLOR"] in ["yes","true"]): - nocolor() - - + if "--color" in sys.argv: + sys.argv.remove("--color") + else: + nocolor() def normpath(mystr): """ @@ -198,7 +199,7 @@ options=[ "--ask", "--alphabetical", "--buildpkg", "--buildpkgonly", -"--changelog", "--columns", "--cols", +"--changelog", "--columns", "--cols", "--color", "--debug", "--deep", "--digest", "--emptytree", @@ -230,7 +231,7 @@ "g":"--getbinpkg", "G":"--getbinpkgonly", "h":"--help", "k":"--usepkg", "K":"--usepkgonly", -"l":"--changelog", +"l":"--changelog", "L":"--color", "n":"--noreplace", "N":"--newuse", "o":"--onlydeps", "O":"--nodeps", "p":"--pretend", "P":"--prune", ====================================== But -L does not work. If someone could tell me how to get shortmappings to work too I would be grateful..
(In reply to comment #8) > After upgrading to portage-2.1_rc2-r3 I got this: > > # emerge --color -vp world > !!! Error: --color is an invalid option. It's not a valid option. After you upgrade you have to reapply the patch. You can call the option anything you want (--color, -L, or whatever).
(In reply to comment #9) > > After upgrading to portage-2.1_rc2-r3 I got this: > > > > # emerge --color -vp world > > !!! Error: --color is an invalid option. > > It's not a valid option. After you upgrade you have to reapply the patch. You > can call the option anything you want (--color, -L, or whatever). > Perhaps I didn't make myself clear. That error was after applying the patch. It was solved by adding --color to options=[...] (which the original patch did not). That does work. Now my problem is that if I understand the contents of emerge correctly adding "L":"--color", to shortmapping=[...] should be sufficient to be able to write -Lvp instead of --color --verbose --pretend. But -Lvp does not bring colors even though --color does. So adding L to shortmapping=[...] only prevents portage from complaining that -L is not a valid option. I cannot figure out how to make -Lvp work as intended. I hope I am more clear now..
The --color=yes,no,auto feature will have to wait until we rewrite the option parsing. However, in portage-2.1.1_pre1-r3 it is now possible to use the NOCOLOR environment variable to force colors when stdout is a pipe. You will have to export NOCOLOR=no in order to do this. NOCOLOR=false will not work because that would break compatibility with the current version of revdep-rebuild.
*** Bug 142480 has been marked as a duplicate of this bug. ***
In svn r4906, I've implement --color < y | n > and deprecated --nocolor. When --color is not specified, it relies on the old NOCOLOR variable and/or stdout auto-detection. I don't think we really need an "auto" option, since that's always been the default behavior and will continue to be as long as --color < y | n > is not specified.
Created attachment 101019 [details, diff] implement --color < y | n > and deprecated --nocolor Here's the patch in case anyone wants to try it. It applies against portage-2.1.2_rc*.
This has been released in 2.1.2_rc1-r3.
