[opensuse-factory] illegible vtty output
More and more utility maintainers apparently think it's helpful to vary foreground colors according to context. It's not helpful - it's an arbitrary and unnecessary usability handicap. Red, blue and green as foreground colors are virtually invisible here. Now that zypper is doing it too, I need to stop it. What's necessary to keep all output in nice legible 2 color mode on the vttys? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 2015-01-02 04:27, Felix Miata wrote:
More and more utility maintainers apparently think it's helpful to vary foreground colors according to context. It's not helpful - it's an arbitrary and unnecessary usability handicap. Red, blue and green as foreground colors are virtually invisible here. Now that zypper is doing it too, I need to stop it. What's necessary to keep all output in nice legible 2 color mode on the vttys?
What is a vtty, and what makes it different from a normal (current software implementation, not the 70s era's) tty? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Jan Engelhardt composed on 2015-01-02 1113 (UTC+0100):
Felix Miata wrote:
More and more utility maintainers apparently think it's helpful to vary foreground colors according to context. It's not helpful - it's an arbitrary and unnecessary usability handicap. Red, blue and green as foreground colors are virtually invisible here. Now that zypper is doing it too, I need to stop it. What's necessary to keep all output in nice legible 2 color mode on the vttys?
What is a vtty, and what makes it different from a normal (current software implementation, not the 70s era's) tty?
A vtty in a Linux distro is a condensed version of virtual terminal, a single physical display with usually 6 virtual displays configured according to /etc/systemd/system/getty.target.wants/ to run agettys or gettys and accept up to 6 logins as if there were 6 displays instead of the one physical one; often called simply tty or vt; and while in multi-user target switched among using Alt-Fn. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 2015-01-02 16:15, Felix Miata wrote:
Jan Engelhardt composed on 2015-01-02 1113 (UTC+0100):
Felix Miata wrote:
Red, blue and green as foreground colors are virtually invisible here. Now that zypper is doing it too, I need to stop it. What's necessary to keep all output in nice legible 2 color mode on the vttys?
What is a vtty [in comparison to just... a tty]?
A vtty in a Linux distro is a condensed version of virtual terminal, a single physical display with usually 6 virtual displays often called simply tty or vt; and while in multi-user target switched among using Alt-Fn.
Uh-huh. So, you don't appear to have a problem with colors (zypper or otherwise) on ptys (as used by screen, kmscon, xterm and ssh), do you? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Jan Engelhardt composed on 2015-01-02 17:07 (UTC+0100):
So, you don't appear to have a problem with colors (zypper or otherwise) on ptys (as used by screen, kmscon, xterm and ssh), do you?
The recent *zypper* change simply served as a *mention*, a *reminder* that the problem exists where I spend much time. It did not imply the problem exists exclusively for zypper or exclusively on vttys. Significantly reduced contrast text is always a problem here. 2/4/16 color ttys and .bashrc containing setterm used to be an escape from (among other things) the gray text on non-white background that has been overwhelming the web. My computer is a tool, not a toy. From tools I expect maximum utility. Dark colors on dark backgrounds and light colors on light backgrounds serve only to depreciate vtty utility. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 01/02/2015 04:13 AM, Jan Engelhardt wrote:
On Friday 2015-01-02 04:27, Felix Miata wrote:
More and more utility maintainers apparently think it's helpful to vary foreground colors according to context. It's not helpful - it's an arbitrary and unnecessary usability handicap. Red, blue and green as foreground colors are virtually invisible here. Now that zypper is doing it too, I need to stop it. What's necessary to keep all output in nice legible 2 color mode on the vttys?
What is a vtty, and what makes it different from a normal (current software implementation, not the 70s era's) tty?
I assumed that Felix was talking about the terminal that you get when you use CTRL-ALT-F1 (or similar). I agree with Felix. I find the new color output difficult to read. I don't understand why people want to inflict this colored text on me. I already have to fix the color "ls" from the shell, the colored "vi". And now zypper is doing it to me. In my case, perhaps it is my color vision ("deuteranomaly" I think). But 5% of the population have that condition, so would be similarly affected. By all means add a "--color" option to zypper. People who like that can force it with a shell alias. Or make it an option in "zypper.conf" or somewhere similar. But for those of us who find it causes reading difficulty, can't the default be left at a standard monochrome? (And why is Thunderbird complaining about "color"? How did it get to be using a Canadian English dictionary?) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, 2 Jan 2015 16:21, Neil Rickert <nrickert@...> wrote:
On 01/02/2015 04:13 AM, Jan Engelhardt wrote:
On Friday 2015-01-02 04:27, Felix Miata wrote:
More and more utility maintainers apparently think it's helpful to vary foreground colors according to context. It's not helpful - it's an arbitrary and unnecessary usability handicap. Red, blue and green as foreground colors are virtually invisible here. Now that zypper is doing it too, I need to stop it. What's necessary to keep all output in nice legible 2 color mode on the vttys?
What is a vtty, and what makes it different from a normal (current software implementation, not the 70s era's) tty?
I assumed that Felix was talking about the terminal that you get when you use CTRL-ALT-F1 (or similar).
I agree with Felix. I find the new color output difficult to read. I don't understand why people want to inflict this colored text on me. I already have to fix the color "ls" from the shell, the colored "vi". And now zypper is doing it to me.
In my case, perhaps it is my color vision ("deuteranomaly" I think). But 5% of the population have that condition, so would be similarly affected.
By all means add a "--color" option to zypper. People who like that can force it with a shell alias. Or make it an option in "zypper.conf" or somewhere similar. But for those of us who find it causes reading difficulty, can't the default be left at a standard monochrome?
On zypper using color: File "/etc/zypp/zypper.conf", Section "[color]", Item "useColors" On a new install it defaulted to "useColors = autodetect" Change that to "useColors = never" and it's gone. Attn.: be aware that a 'user-private' ~/.zypper.conf could exist. - Yamaban. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2015-01-02 16:53, Yamaban wrote:
On Fri, 2 Jan 2015 16:21, Neil Rickert <nrickert@...> wrote:
I agree with Felix. I find the new color output difficult to read. I don't understand why people want to inflict this colored text on me. I already have to fix the color "ls" from the shell, the colored "vi". And now zypper is doing it to me.
In my case, perhaps it is my color vision ("deuteranomaly" I think). But 5% of the population have that condition, so would be similarly affected.
On zypper using color: File "/etc/zypp/zypper.conf", Section "[color]", Item "useColors"
On a new install it defaulted to "useColors = autodetect" Change that to "useColors = never" and it's gone.
If programs are defaulting to display with colour on terminals, it would make sense to have a global environment option honoured by all programs, telling them to use colour or not. I don't remember which one, now, but I have seen programs with colour choices that were nearly invisible to me (white on yellow?), and I have normal sight. The choices that work on a black terminal fail on a terminal that by default is whitish, like xterm. And the other way round. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 01/02/2015 01:34 PM, Carlos E. R. wrote:
I don't remember which one, now, but I have seen programs with colour choices that were nearly invisible to me (white on yellow?), and I have normal sight. The choices that work on a black terminal fail on a terminal that by default is whitish, like xterm. And the other way round.
One that gets me is in vi, when I have a line commented out with a #. That produces dark blue on black background that's impossible to read. Who's the genius that dreams up this stuff? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
James Knott wrote:
On 01/02/2015 01:34 PM, Carlos E. R. wrote:
I don't remember which one, now, but I have seen programs with colour choices that were nearly invisible to me (white on yellow?), and I have normal sight. The choices that work on a black terminal fail on a terminal that by default is whitish, like xterm. And the other way round.
One that gets me is in vi, when I have a line commented out with a #.
Just for the record - syntax highlighting in editors has been there for years, it's not really on-topic.
That produces dark blue on black background that's impossible to read. Who's the genius that dreams up this stuff?
Yeah, that one is impossible, but it is intended for people who have a light background colour: http://vim.wikia.com/wiki/Better_colors_for_syntax_highlighting For syntax highlighting there are two sets of default color maps: One for a light and another one for a dark background. If you have a black background, use the following command to get a better color map for syntax highlighting: :set background=dark -- Per Jessen, Zürich (2.9°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2015-01-02 20:44, Per Jessen wrote:
Yeah, that one is impossible, but it is intended for people who have a light background colour: ... :set background=dark
Then the program should read the background colour before deciding on a theme, not require the user to enter a command to change it. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
James Knott composed on 2015-01-02 13:42 (UTC-0500):
One that gets me is in vi, when I have a line commented out with a #. That produces dark blue on black background that's impossible to read. Who's the genius that dreams up this stuff?
It could be a case of monkey see, monkey do. That's how it seems to be in web design. On the shell cmdline, we had fdisk's author's to lead the way, and maybe other(s) (besides ls, which I rarely use except via aliases that do not declare colorization) that fail to come to mind or I never noticed. People with anything worse than average corrected vision simply do not use computers as a primary component of their jobs or main hobbies on longer than a transitory basis. Based on years of observations using their work products, few designing web apps or PC apps, including Linux distro tool makers, exhibit significant consciousness while working of what impact their activity has on people who have below average vision but nevertheless have no need for, or should have no need for, assistive technology for using the Internet or a PC. Viewed from the other direction, what this means is people writing software, as a group, have better than average vision, and are thus less likely than average to understand and employ A11Y automatically in their work products. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 01/02/2015 11:51 PM, Felix Miata wrote:
James Knott composed on 2015-01-02 13:42 (UTC-0500):
One that gets me is in vi, when I have a line commented out with a #. That produces dark blue on black background that's impossible to read. Who's the genius that dreams up this stuff? It could be a case of monkey see, monkey do. That's how it seems to be in web design. On the shell cmdline, we had fdisk's author's to lead the way, and maybe other(s) (besides ls, which I rarely use except via aliases that do not declare colorization) that fail to come to mind or I never noticed.
People with anything worse than average corrected vision simply do not use computers as a primary component of their jobs or main hobbies on longer than a transitory basis. Based on years of observations using their work products, few designing web apps or PC apps, including Linux distro tool makers, exhibit significant consciousness while working of what impact their activity has on people who have below average vision but nevertheless have no need for, or should have no need for, assistive technology for using the Internet or a PC.
Viewed from the other direction, what this means is people writing software, as a group, have better than average vision, and are thus less likely than average to understand and employ A11Y automatically in their work products.
I have also seen web sides with extremely poor colour choice. Some are so bad I avoid them. While I have normal vision and can read them, it's such a pain to do so. I feel sorry for those who have vision impairments that prevent them from seeing a lot of things. This is why I find the trend to low contrast displays troubling. There are many who cannot read them, no matter how hard they try. Almost as bad are wild colour combinations that simply look terrible. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 2015-01-02 19:34, Carlos E. R. wrote:
The choices that work on a black terminal fail on a terminal that by default is whitish, like xterm. And the other way round.
Which is why we only chose colors for zypp that work in both black and white environments; in particular, blue, gray and white have been avoided. However, certain terminal applications (and xterm is one of them) have badly-chosen default RGB values for the 16 standard color slots. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Carlos E. R. composed on 2015-01-02 19:34 (UTC+0100):
If programs are defaulting to display with colour on terminals, it would make sense to have a global environment option honoured by all programs, telling them to use colour or not.
Given that zypper has an autodetect mode as default, it would seem such a thing already exists, and therefore it would remain only for those other than those who can understand zypper code to somehow discover what that is. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 03.01.2015 um 05:10 schrieb Felix Miata:
Carlos E. R. composed on 2015-01-02 19:34 (UTC+0100):
If programs are defaulting to display with colour on terminals, it would make sense to have a global environment option honoured by all programs, telling them to use colour or not.
Given that zypper has an autodetect mode as default, it would seem such a thing already exists,
No. "autodetect" in this case usually means "if output is to a terminal (== interactive), then use colour, else don't". That's how it is for grep etc. and I guess zypper is the same in this regard. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2015-01-03 13:29, Stefan Seyfried wrote:
Am 03.01.2015 um 05:10 schrieb Felix Miata:
Carlos E. R. composed on 2015-01-02 19:34 (UTC+0100):
If programs are defaulting to display with colour on terminals, it would make sense to have a global environment option honoured by all programs, telling them to use colour or not.
Given that zypper has an autodetect mode as default, it would seem such a thing already exists,
No. "autodetect" in this case usually means "if output is to a terminal (== interactive), then use colour, else don't".
That's how it is for grep etc. and I guess zypper is the same in this regard.
Right. Perhaps, if there is no agreement in a common variable honoured by all programs to limit their colour output, then perhaps a little script, or gadget in yast, that creates the different settings for all known programs. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlSoAdYACgkQtTMYHG2NR9UkQACfcIW4+DbVacFjXzLZ9E8qduWV AGgAoJPDFcCD7VVw9/1rhNwRSPFm0fJC =EKrX -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Yamaban composed on 2015-01-02 16:53 (UTC+0100):
On Friday 2015-01-02 04:27, Felix Miata wrote:
More and more utility maintainers apparently think it's helpful to vary foreground colors according to context. It's not helpful - it's an arbitrary and unnecessary usability handicap. Red, blue and green as foreground colors are virtually invisible here. Now that zypper is doing it too, I need to stop it. What's necessary to keep all output in nice legible 2 color mode on the vttys?
On zypper using color: File "/etc/zypp/zypper.conf", Section "[color]", Item "useColors"
Zypper is hardly the only problem. One of the reasons for using vttys in the first place is escape from tiny text, useless itty bitty icons[1], suboptimal contrast, and busyness or overall clutter in a GUI environment, a place to focus on a single task with minimal distractions. Reducing contrast using colors adds distraction while doing what reducing contrast usually does[2], reducing legibility and in turn inhibiting utility, negative A11Y.
On a new install it defaulted to "useColors = autodetect"
The existence of "autodetect" would seem to imply query for an environmental or global config setting that could be made to return 4-color, 2-color or monochrome. To address my OP, where and how could that be done? Something in /etc/profile.local maybe?
Change that to "useColors = never" and it's gone.
Attn.: be aware that a 'user-private' ~/.zypper.conf could exist.
Wouldn't FHS put that in ~/.config/zypper.conf instead? That's where YaST2, chromium, fontconfig, gconf, gtk*, mc and several others now live. And .fdisk.conf, .gdisk.conf, .sfdisk.conf perhaps, ad inifinitum? [1] http://www.nngroup.com/articles/icon-usability/ [2] http://colorusage.arc.nasa.gov/legib_1.php -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 02.01.2015 um 23:06 schrieb Felix Miata:
Yamaban composed on 2015-01-02 16:53 (UTC+0100):
On Friday 2015-01-02 04:27, Felix Miata wrote:
More and more utility maintainers apparently think it's helpful to vary foreground colors according to context. It's not helpful - it's an arbitrary and unnecessary usability handicap. Red, blue and green as foreground colors are virtually invisible here. Now that zypper is doing it too, I need to stop it. What's necessary to keep all output in nice legible 2 color mode on the vttys?
On zypper using color: File "/etc/zypp/zypper.conf", Section "[color]", Item "useColors"
Zypper is hardly the only problem.
export TERM=dumb :-) TERM=ansi-m might actually work. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Saturday 2015-01-03 00:08, Stefan Seyfried wrote:
On zypper using color: File "/etc/zypp/zypper.conf", Section "[color]", Item "useColors"
Zypper is hardly the only problem.
export TERM=dumb :-)
TERM=ansi-m might actually work.
Hardly. zypper's "autodetect" logic is really broken. TERM=dumb indicates your terminal is as dumb as a line printer, i.e. limited cursor movement, which is not something you want programs to assume if all you want is getting rid of color. In fact, it precludes some programs from running: 01:43 localhorse:~/bin > TERM=dumb pine Your terminal, of type "dumb", is lacking functions needed to run alpine. Using TERM=vt100 or TERM=ansi-m works better, though ideally, someone should create a colorless terminfo entry based upon the modern "xterm" and "screen" definitions rather than vt100/ansi-m. Which brings us back to zypper: it should use ncurses/terminfo to determine color mode, not TERM==dumb. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 2015-01-02 23:06, Felix Miata wrote:
Zypper is hardly the only problem. One of the reasons for using vttys in the first place is escape from tiny text
What precludes you from running an xterm with a suitable font size so as to fill the screen in at least one dimension?
Wouldn't FHS put that in ~/.config/zypper.conf instead?
XDG yes. However, zypper does not follow XDG (yet, at least). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Jan Engelhardt composed on 2015-01-03 01:37 (UTC+0100):
Felix Miata wrote:
Zypper is hardly the only problem. One of the reasons for using vttys in the first place is escape from tiny text
What precludes you from running an xterm with a suitable font size so as to fill the screen in at least one dimension?
Besides being in multi-user to fix an unusable X, or upgrading a minimalist installation to include any X at all after setting solver.onlyRequires = true to keep it as svelte as practical? ;-) Interesting that you asked about xterm specifically. I've never figured out how to make xterm text more than about 60% of a comfortable size. These seem to answer that A11Y obstacle: https://bugzilla.opensuse.org/show_bug.cgi?id=835299 (WONTFIX) and https://bugzilla.opensuse.org/show_bug.cgi?id=833437 (open) OTOH, Konsole text I can acceptably control text size in, but only globally, not on a window by window basis remembered across sessions, users and installations. Using vttys avoids that impediment by usually having bigger text, in full screen, or did, until cmdline utility developers decided using colors on vttys should be both implemented *and* applied by default. Color only recently appeared in zypper's man page. It and its reference to zypper.conf make no mention how "autodetect" determines what to do, where or to what it looks in order to decide whether to use colors.
Wouldn't FHS put that in ~/.config/zypper.conf instead?
XDG yes. However, zypper does not follow XDG (yet, at least). -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Saturday 2015-01-03 03:55, Felix Miata wrote:
Interesting that you asked about xterm specifically. I've never figured out how to make xterm text more than about 60% of a comfortable size.
xterm -fa "DejaVu Sans Mono:bold:italic:size=32:matrix=0.85 0 0 1" (choose Xft options as you like). Now all you need is a good font[1] and a sane color set[2]. [1] Andale Mono, DejaVu Sans Mono, Droid Sans Mono, Latin Modern Mono, Adobe Source Code Pro (all in openSUSE one way or another) Or for true fans: Fixedsys Excelsior: http://fixedsysexcelsior.com/ Consoleet B1: http://inai.de/projects/consoleet/ [2] VGA Palette (desatured): https://git.netitwork.net/pub/cgit.cgi/hxtools/tree/suser/fxterm
Using vttys avoids that impediment by usually having bigger text
When the x86 VT console is in one of the classic VGA text modes, they are limited to loading 8x8/8x14/8x16 fonts. When however driven by framebuffer, arbitrary bitmap fonts can be loaded with setfont, and principally all fonts can be loaded. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 02.01.2015 um 04:27 schrieb Felix Miata:
More and more utility maintainers apparently think it's helpful to vary foreground colors according to context. It's not helpful - it's an arbitrary and unnecessary usability handicap. Red, blue and green as foreground colors are virtually invisible here. Now that zypper is doing it too, I need to stop it. What's necessary to keep all output in nice legible 2 color mode on the vttys?
I have not tried it, but from the help text, I assume that [color] useColors = never in /etc/zypp/zypper.conf would do. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (9)
-
Carlos E. R. -
Carlos E. R. -
Felix Miata -
James Knott -
Jan Engelhardt -
Neil Rickert -
Per Jessen -
Stefan Seyfried -
Yamaban