On Monday 07 August 2017 11:26:16 Greg Wooledge wrote: > On Mon, Aug 07, 2017 at 11:02:10AM -0400, Gene Heskett wrote: > > On Monday 07 August 2017 08:39:46 Greg Wooledge wrote: > > > Also while I'm here: the garish colors of apt(8) are not the #1 > > > reason I switched back to apt-get(8), but they are #2. Whoever > > > chose the colors clearly doesn't use a terminal with a white > > > background, because yellow on white is simply unreadable. > > > > That seems odd, and would tend to make me think of using the > > educational club. > > I don't understand; what part seems odd? My use of terminals with > white backgrounds? That's fair. Most Linux kids these days seem to > prefer black backgrounds. > As do I, but at 82 and counting, I am hardly a kid. ;-)
> Or do you dispute the fact that apt uses yellow foreground text when > you do "apt update"? I see the link namestring and path in a medium red while its fetching the lists, but there is nothing to update ATM, and for me, the most important site, buildbot.linuxcnc.org has been down since Saturday,so everything else is in medium white. And I don't recall ever seeing anything with yellow characters on that screen. About time to email Sebastion and advise him the buildbot seems to have crashed, I can't even ping it. > In TERM=rxvt-unicode, apt uses the escape sequence ESC[33m to produce > yellow text. I just captured it using "script" and verified this. > This is slightly different from the ESC[38;5;3m that "tput setaf 3" > uses, but they both give me yellow fg text when tested interactively. > > > The only machine I have that uses apt as default, is a raspi running > > jessie, and its happy as a clam, either on its full 16 bit color > > framebuffer screen, or on a logged in terminal-4.8 here. > > The Linux virtual console has a black background by default. > Rxvt has white. Xterm also used to have a white background, but > Debian seems to have changed that at some point. (xterm(1) still > speaks of "the X defaults (black text on a white background)" but only > in a general sense.) > > > LS_COLORS=rs=0:di=01;34:[...] > > Are you suggesting that apt(8) uses LS_COLORS? That would surprise > me. It's most defintely not in the man page. Then again, the word > "color" is nowhere in that man page. > > It would also surprise me, because LS_COLORS tells ls(1) how to use > colors based on file types and extensions, which are not something > that apt(8) deals with. apt deals with package names, package > descriptions, retrievals and retrieval failures, etc. I do not believe that apt controls the colors, that is all in the processing of the text as its being rendered for display in your native language. So it could very well be using LS_COLORS. Doing an "env| grep .deb" shows that a .deb filename is colored by *.tz=01;31:*.deb=01;31:*.rpm=01;31, so are many of the common package extensions, which is why I included the ones on either side of the '*.deb=' as an example above, but it looks like most if not all of the common package names where the files are compressed by any compressor, are also colored the same. I of course don't know that for a fact, but all the clues seem to point to that conclusion. However, I have grepped that system without finding LS_COLORS. Something is setting that as an env variable, but I cannot find it. There is a /usr/bin/dircolors but its a binary, and more than dircolors is being set in the env. So I've failed, again. Oldtimers? Or have I? An hour later, take a look at /home/$usr/.themes/PiX/GTK-3.0/README. I have a headache trying to figure it out, but I have a gut feeling it could be related to the LS_COLORS env variable. The PiX part of the path might be different if your is not a pi of course. Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene>
