10:49 p.m.
In Fedora the bash prompt is not colored or highlighted by default.
I personally find this a usability issue: it makes it hard to find previous
commands between long outputs when scrolling back in a terminal. Of course
in my own host I have a custom prompt, but it means whenever I am using a
different Fedora/Centos/RHEL system or vm, the prompt is not highlighted by
default, which I miss.
Since I spent a little time thinking about and investigating this I thought
I would write to start a discussion here.
I noticed that Ubuntu has a bold green and blue prompt and NixOS has a
green one by default, though not Archlinux or OpenSuSE I think.
I think it would be nice to have a distinctive prompt by default, or at
least a very easy way to get one permanently (ie in a single command: even
if that were `dnf install bash-color-prompt` or running say `colorprompt`
once).
For example I could suggest we change the default fedora bash prompt from:
PS1="[\u@\h \W]\\$ "
to something like:
PS1="\[\e[\${PROMPT_COLOR}m\][\u@\h \W]\[\e[0m\]\\$ ".
Then the PROMPT_COLOR envvar would make it easy for users to change or
customize their prompt coloring anyway.
For example with PROMPT_COLOR="1;32" one gets a bold green prompt, which
seems readable in both dark or light terminals.
What do people think overall? Are there other pros and cons of a color
prompt?
Any better ideas or direction?
Jens
12:48 a.m.
On Mon, May 22, 2023 at 3:50 AM Jens-Ulrik Petersen <petersen(a)redhat.com> wrote:
In Fedora the bash prompt is not colored or highlighted by default.
I personally find this a usability issue: it makes it hard to find previous commands
between long outputs when scrolling back in a terminal. Of course in my own host I have a
custom prompt, but it means whenever I am using a different Fedora/Centos/RHEL system or
vm, the prompt is not highlighted by default, which I miss.
Since I spent a little time thinking about and investigating this I thought I would write
to start a discussion here.
I noticed that Ubuntu has a bold green and blue prompt and NixOS has a green one by
default, though not Archlinux or OpenSuSE I think.
I think it would be nice to have a distinctive prompt by default, or at least a very easy
way to get one permanently (ie in a single command: even if that were `dnf install
bash-color-prompt` or running say `colorprompt` once).
For example I could suggest we change the default fedora bash prompt from:
PS1="[\u@\h \W]\\$ "
to something like:
PS1="\[\e[\${PROMPT_COLOR}m\][\u@\h \W]\[\e[0m\]\\$ ".
Maybe make it ${PROMPT_COLOR:-1;32} to have a default value without
polluting the environment?
Then the PROMPT_COLOR envvar would make it easy for users to change
or customize their prompt coloring anyway.
For example with PROMPT_COLOR="1;32" one gets a bold green prompt, which seems
readable in both dark or light terminals.
What do people think overall? Are there other pros and cons of a color prompt?
Any better ideas or direction?
I also have a colored prompt and I find the default prompt annoying
when I run a live system. I don't expect terminal users to be bothered
by this, as long as it doesn't conflict with their dotfiles (for those
who maintain theirs).
Dridi
11:23 p.m.
On Mon, May 22, 2023 at 1:49 PM Dridi Boukelmoune <
dridi.boukelmoune(a)gmail.com> wrote:
On Mon, May 22, 2023 at 3:50 AM Jens-Ulrik Petersen
<petersen(a)redhat.com>
wrote:
> For example I could suggest we change the default fedora bash prompt
from:
> PS1="[\u@\h \W]\\$ "
> to something like:
> PS1="\[\e[\${PROMPT_COLOR}m\][\u@\h \W]\[\e[0m\]\\$ ".
Maybe make it ${PROMPT_COLOR:-1;32} to have a default value without
polluting the environment?
Thanks for the suggesion
Personally I think that's reasonable: however I was also being cautious in
the sense of making it easy for people to opt out of the color prompt.
Also it is not really pollution: PROMPT_COLOUR is actually used for each
prompt and in theory it could be changed dynamically (maybe by
PROMPT_COMMAND etc, shrug?).
But if there is broad consensus wouldn't mind I guess.
Jens
11:46 p.m.
On Tue, May 23, 2023 at 12:24 AM Jens-Ulrik Petersen
<petersen(a)redhat.com> wrote:
On Mon, May 22, 2023 at 1:49 PM Dridi Boukelmoune <dridi.boukelmoune(a)gmail.com>
wrote:
>
> On Mon, May 22, 2023 at 3:50 AM Jens-Ulrik Petersen <petersen(a)redhat.com>
wrote:
> > For example I could suggest we change the default fedora bash prompt from:
> > PS1="[\u@\h \W]\\$ "
> > to something like:
> > PS1="\[\e[\${PROMPT_COLOR}m\][\u@\h \W]\[\e[0m\]\\$ ".
>
> Maybe make it ${PROMPT_COLOR:-1;32} to have a default value without
> polluting the environment?
Thanks for the suggesion
Personally I think that's reasonable: however I was also being cautious in the sense
of making it easy for people to opt out of the color prompt.
Also it is not really pollution: PROMPT_COLOUR is actually used for each prompt and in
theory it could be changed dynamically (maybe by PROMPT_COMMAND etc, shrug?).
But if there is broad consensus wouldn't mind I guess.
Both Debian/Ubuntu and SUSE distributions color the prompt for
different purposes:
* Debian/Ubuntu colors the normal user prompt and leave the root user
prompt alone
* SUSE colors the root user prompt and leaves the normal user prompt alone
I actually would prefer that we color both, and make it obvious that
"root" is special. We should account for common color-blindness
issues, though.
--
真実はいつも一つ！/ Always, there's only one truth!
12:08 a.m.
On Tue, May 23, 2023 at 12:47 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
I actually would prefer that we color both, and make it obvious that
"root" is special. We should account for common color-blindness
issues, though.
Sure, I think I agree: perhaps purple for root?
I am all for "color blind testing" (though I am not completely sure that
"color-blind" is the right term here
though I am not an a11y expert - I thought color blind is more about
differentiating different colors like green and red,
but if you mean visual impairment/contrast/readability then I completely
agree).
I think in the end it will come down also to wider user testing since there
are so many different terminals
and color palettes around.
Anyway that's why I proposed green since it seems to have reasonable
contrast for both light and dark terminals (unlike blue/cyan/yellow often).
I assume that may also be why Ubuntu and Nixos went with green.
Jens
6:07 a.m.
On Tue, May 23, 2023 at 1:08 AM Jens-Ulrik Petersen <petersen(a)redhat.com> wrote:
On Tue, May 23, 2023 at 12:47 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
>
> I actually would prefer that we color both, and make it obvious that
> "root" is special. We should account for common color-blindness
> issues, though.
Sure, I think I agree: perhaps purple for root?
I am all for "color blind testing" (though I am not completely sure that
"color-blind" is the right term here
though I am not an a11y expert - I thought color blind is more about differentiating
different colors like green and red,
but if you mean visual impairment/contrast/readability then I completely agree).
I think in the end it will come down also to wider user testing since there are so many
different terminals
and color palettes around.
Anyway that's why I proposed green since it seems to have reasonable contrast for
both light and dark terminals (unlike blue/cyan/yellow often).
I assume that may also be why Ubuntu and Nixos went with green.
Basically, I mean "don't use red for root and green for regular user"
since that cannot be distinguished by red+green colorblind people.
Purple may work for root to fix that.
--
真実はいつも一つ！/ Always, there's only one truth!
10:10 a.m.
On Tue, May 23, 2023 at 07:07:17AM -0400, Neal Gompa wrote:
On Tue, May 23, 2023 at 1:08 AM Jens-Ulrik Petersen
<petersen(a)redhat.com> wrote:
>
> On Tue, May 23, 2023 at 12:47 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
>>
>> I actually would prefer that we color both, and make it obvious that
>> "root" is special. We should account for common color-blindness
>> issues, though.
>
>
> Sure, I think I agree: perhaps purple for root?
>
> I am all for "color blind testing" (though I am not completely sure that
"color-blind" is the right term here
> though I am not an a11y expert - I thought color blind is more about differentiating
different colors like green and red,
> but if you mean visual impairment/contrast/readability then I completely agree).
> I think in the end it will come down also to wider user testing since there are so
many different terminals
> and color palettes around.
>
> Anyway that's why I proposed green since it seems to have reasonable contrast
for both light and dark terminals (unlike blue/cyan/yellow often).
> I assume that may also be why Ubuntu and Nixos went with green.
>
Basically, I mean "don't use red for root and green for regular user"
since that cannot be distinguished by red+green colorblind people.
Colorblind person here. It's not a simple thing because everyone who has some
level of color blindness will be different than someone else. I may be able
to see more or different reds and greens than another person.
I can say with 100% certainty that if default prompts are gain colors in
Fedora, I will turn that off for myself. I try not to use colors for anything
(again, special user case here...someone once described my mutt configuration
as "brutalist"). That said, I don't care what the defaults are, just make
it
so I can easily turn that stuff off.
Shell customizations are very personal anyway and everyone has favorites. I
suggest packaging yours as an /etc/profile.d file in a Copr project, then
enabling that repo when you install or set up a VM.
Purple may work for root to fix that.
$ vs. # has long been established as the distinguisher between a non-root and
root shell. That's what I would rely on. ¯\_(ツ)_/¯
Color wise, purple would actually be really bad for me because I can't
distinguish that from red in many cases. But it usually registers as
"different" than green.
(with apologies to zsh, but we all have wild zshrc files anyway and some us
spell "$" as "%".)
--
David Cantrell <dcantrell(a)redhat.com>
Red Hat, Inc. | Boston, MA | EST5EDT
1:09 p.m.
In my experience, “colorblindness” is generally understood to include a range of color
vision “anomalies.” I have the most common form, deuteranomaly. Green does not look as
bright as other colors to me, and I have a hard time distinguishing greenish colors from
reddish colors when they are desaturated (like greenish-brown versus reddish-brown), or
when looking at fine points or lines rather than large areas of color. I can still easily
distinguish bright green from bright red, even in a small area, but it’s very difficult to
distinguish a small amber LED from a green one.
It’s best to avoid using color to communicate essential information with no backup
mechanism; to use something like the contrast ratio formulas from WCAG 2.2 to ensure
adjacent colors contrast sufficiently in luminance and not only in hue; and to
particularly avoid contrasting colors that are both reddish or greenish when possible,
since these are the most troublesome for the largest number of people.
On Tue, May 23, 2023, at 1:08 AM, Jens-Ulrik Petersen wrote:
> On Tue, May 23, 2023 at 12:47 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
>> I actually would prefer that we color both, and make it obvious that
>> "root" is special. We should account for common color-blindness
>> issues, though.
>
> Sure, I think I agree: perhaps purple for root?
>
> I am all for "color blind testing" (though I am not completely sure
> that "color-blind" is the right term here
> though I am not an a11y expert - I thought color blind is more about
> differentiating different colors like green and red,
> but if you mean visual impairment/contrast/readability then I
> completely agree).
> I think in the end it will come down also to wider user testing since
> there are so many different terminals
> and color palettes around.
>
> Anyway that's why I proposed green since it seems to have reasonable
> contrast for both light and dark terminals (unlike blue/cyan/yellow
> often).
> I assume that may also be why Ubuntu and Nixos went with green.
>
> Jens
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
2:05 p.m.
On Tue, May 23, 2023, at 1:08 AM, Jens-Ulrik Petersen wrote:
On Tue, May 23, 2023 at 12:47 PM Neal Gompa
<ngompa13(a)gmail.com> wrote:
> I actually would prefer that we color both, and make it obvious that
> "root" is special. We should account for common color-blindness
> issues, though.
Sure, I think I agree: perhaps purple for root?
I think if we avoid the need to distinguish between redish and greenish, it's OK.
Redish includes red, pink, magenta. Greenish includes green, cyan, sky blue.
Ergo, you can use green or red, you just don't want to make the A vs B red and green
because they will look the same to anyone with a red/green color discrimination
limitation.
Much less common is blue/yellow. I don't have data handy but off the top of my head,
tritonopia and tritonomaly cases will notice the difference between purple vs orange OK.
We do have publicly available math to predict the discrimination of various nopias and
nomalies; I'm not sure exactly how it's implemented in GIMP but there is a
"color deficient vision" filter should give an adequate idea whether or not a
design has expected/sufficient/desired differentiation of elements based on color. (We
don't actually know what anyone's color experience is, as it turns out. That's
what I mean by this.)
https://docs.gimp.org/2.10/en/gimp-display-filter-dialog.html
I am all for "color blind testing" (though I am not completely sure that
"color-blind" is the right term here
though I am not an a11y expert - I thought color blind is more about differentiating
different colors like green and red,
but if you mean visual impairment/contrast/readability then I completely agree).
It's common vernacular. But it's more interesting than this term because it
suggests one variety or effect. There are more than several. If we consider "color
blind" means total lack of color discrimination, or monochromat - they are rare. I
don't even know the number. Dichromats are much more common, where these are broken
down into whether it's the long, medium, or short wavelngth cone is missing
(entirely). The world does have some color, we think, at least there's discrimination
possible. But it's of course limited without a third color receptor. Quite a lot more
common are tricromats with anomalous spectral sensitivity of one of the receptors, i.e.
the long wavelength cone might be green shifted, so it's more sensitive to yellows
than the "standard observer". This then questions the whole age old concept of
the standard observer, and for a while now it's been suspected we need more than one
standard observer - because, well, they did all these tests in the early 1900's with
something like 50 people. Seriously. And that's the data still largely used today.
Anyway...
I tend to call it a color discrimination variance. Or limitation.
Oh and there are such folks as quadchromats. They have four color receptors. And then
still there's the entire non-human animal kingdom full of completely different
receptor peak wavelenth sensitivities, including tetrachromats and pentachromats.
I think in the end it will come down also to wider user testing since
there are so many different terminals
and color palettes around.
Anyway that's why I proposed green since it seems to have reasonable contrast for
both light and dark terminals (unlike blue/cyan/yellow often).
I assume that may also be why Ubuntu and Nixos went with green.
Green is an efficient color choice. It tends to appear to the brightest. Part of this
relates to the luminosity function of human vision which has a peak wavelength that
happens to be the same as the medium wavelength photo receptor (i.e. green). So given the
same amount of radiant energy emitted across the visible spectrum, green will appear to
be the brightest.
Light purple is OK, Blue, indigo, or yellow tends to be harder to to detect complex shapes
(like letters and numbers) but I'm not sure of the reason(s).
--
Chris Murphy
10:57 a.m.
On Wed, 24 May 2023 15:05:07 -0400
"Chris Murphy" <lists(a)colorremedies.com> wrote:
Green is an efficient color choice. It tends to appear to the
brightest. Part of this relates to the luminosity function of human
vision which has a peak wavelength that happens to be the same as the
medium wavelength photo receptor (i.e. green). So given the same
amount of radiant energy emitted across the visible spectrum, green
will appear to be the brightest.
Light purple is OK, Blue, indigo, or yellow tends to be harder to to
detect complex shapes (like letters and numbers) but I'm not sure of
the reason(s).
I'm attaching an image of a prompt with yellow, my default, and a
prompt with green using Jens' prompt suggestion. I find the green too
bright, I would prefer it with a little more black in it. But I would
just override it anyway.
A long time ago I had a monochrome crt that defaulted to a sort of burnt
orange which also worked fine.
1:50 a.m.
On 25 May 2023, at 16:58, stan via devel
<devel(a)lists.fedoraproject.org> wrote:
I find the green too
bright, I would prefer it with a little more black in it.
The colours that a particular users sees on particular hardware will vary a large amount.
Also the inability of CLI code to know if dark mode is in used or not
means default colour choices can make text difficult to read.
Barry
6:14 a.m.
AFAIK Gnome Terminal is the only terminal that uses white background by
default. To my knowledge, all the other terminals use black background.
On 26. 5. 2023 8:50, Barry wrote:
> On 25 May 2023, at 16:58, stan via devel <devel(a)lists.fedoraproject.org>
wrote:
>
> I find the green too
> bright, I would prefer it with a little more black in it.
The colours that a particular users sees on particular hardware will vary a large
amount.
Also the inability of CLI code to know if dark mode is in used or not
means default colour choices can make text difficult to read.
Barry
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
--
Marián Konček
12:33 p.m.
Marián Konček wrote:
AFAIK Gnome Terminal is the only terminal that uses white background
by
default. To my knowledge, all the other terminals use black background.
If you can get *all* the terminal emulators amended so that users can
configure the prompt color in the same dialog box where they configure
the background and text colors, and also get that configuration to take
effect across SSH, even between different operating systems, *only then*
is it somewhat reasonable to expect users to also choose another prompt
color when they set the background color.
As long as the prompt is configured in a completely different place
than the background, and separately on each server, the prompt must be
readable by default on both light and dark backgrounds.
Björn Persson
1:55 p.m.
On 27/05/23, Peter Oliver wrote:
On Fri, 26 May 2023, Marián Konček wrote:
> AFAIK Gnome Terminal is the only terminal that uses white background by
> default. To my knowledge, all the other terminals use black background.
Both xterm and rxvt default to a white background.
White background is a good choice for accessibility iirc.
Kushal
--
Public Interest Technologist
CPython Core Developer
Director, Python Software Foundation
https://kushaldas.in
5:05 p.m.
Am 08.07.23 um 22:44 schrieb Barry:
> On 8 Jul 2023, at 19:56, Kushal Das <mail(a)kushaldas.in> wrote:
>
> White background is a good choice for accessibility iirc.
Isn’t is contrast that matters not any particular background?
On the contrary it helps, a white background helps the human visual
system to distinguish patterns better then a black on do but this is
just one aspect to prefer the one or the other ... :-)
--
Leon
2:04 a.m.
Il 09/07/23 00:05, Leon Fauster via devel ha scritto:
Am 08.07.23 um 22:44 schrieb Barry:
>
>> On 8 Jul 2023, at 19:56, Kushal Das <mail(a)kushaldas.in> wrote:
>>
>> White background is a good choice for accessibility iirc.
> Isn’t is contrast that matters not any particular background?
On the contrary it helps, a white background helps the human visual
system to distinguish patterns better then a black on do but this is
just one aspect to prefer the one or the other ... :-)
I also like white background while reading things on a support using
natural light, but when it comes to support using backlight I prefer
black background as I found that to be less eye tiresome (I don't know
what science/researches say about this, it's just my personal experience).
Anyway, I don't care about defaults as far as I can found the way to set
back settings with ease.
Mattia
9:06 a.m.
On Sun Jul 9, 2023 at 3:04 AM EDT, Mattia Verga via devel wrote:
> Il 09/07/23 00:05, Leon Fauster via devel ha scritto:
> > Am 08.07.23 um 22:44 schrieb Barry:
> >>
> >>> On 8 Jul 2023, at 19:56, Kushal Das <mail(a)kushaldas.in> wrote:
> >>>
> >>> White background is a good choice for accessibility iirc.
> >> Isn’t is contrast that matters not any particular background?
> >
> > On the contrary it helps, a white background helps the human visual
> > system to distinguish patterns better then a black on do but this is
> > just one aspect to prefer the one or the other ... :-)
> >
> I also like white background while reading things on a support using
> natural light, but when it comes to support using backlight I prefer
> black background as I found that to be less eye tiresome (I don't know
> what science/researches say about this, it's just my personal experience)
1:21 a.m.
Hi Jens,
Jens-Ulrik Petersen <petersen(a)redhat.com> writes:
In Fedora the bash prompt is not colored or highlighted by default.
I personally find this a usability issue: it makes it hard to find previous
commands between long outputs when scrolling back in a terminal. Of course
in my own host I have a custom prompt, but it means whenever I am using a
different Fedora/Centos/RHEL system or vm, the prompt is not highlighted by
default, which I miss.
Since I spent a little time thinking about and investigating this I thought
I would write to start a discussion here.
I noticed that Ubuntu has a bold green and blue prompt and NixOS has a
green one by default, though not Archlinux or OpenSuSE I think.
I think it would be nice to have a distinctive prompt by default, or at
least a very easy way to get one permanently (ie in a single command: even
if that were `dnf install bash-color-prompt` or running say `colorprompt`
once).
For example I could suggest we change the default fedora bash prompt from:
PS1="[\u@\h \W]\\$ "
to something like:
PS1="\[\e[\${PROMPT_COLOR}m\][\u@\h \W]\[\e[0m\]\\$ ".
Then the PROMPT_COLOR envvar would make it easy for users to change or
customize their prompt coloring anyway.
For example with PROMPT_COLOR="1;32" one gets a bold green prompt, which
seems readable in both dark or light terminals.
What do people think overall? Are there other pros and cons of a color
prompt?
Any better ideas or direction?
I think your suggestion is very unobtrusive and a great quality of life
improvement! So please go for it!
My only suggestion would be to double check with someone who's familiar
with accessibility with respect to color blindness to find the best
possible default, so that color blind users will not have an even harder
time spotting the prompt.
Cheers,
Dan
9:42 a.m.
FWIW Haiku uses bash and has a prompt which changes colour (green/red)
depending on whether the status code of the last command was good or
bad. I found this surprisingly useful. They use:
\[`if [ $? = 0 ]; then echo "\e[32m"; else echo "\e[31m";
fi`\]\w[\e[0m\]>
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
9:56 a.m.
Once upon a time, Richard W.M. Jones <rjones(a)redhat.com> said:
FWIW Haiku uses bash and has a prompt which changes colour
(green/red)
depending on whether the status code of the last command was good or
bad. I found this surprisingly useful. They use:
\[`if [ $? = 0 ]; then echo "\e[32m"; else echo "\e[31m";
fi`\]\w[\e[0m\]>
I've used something similar in my prompt for a while, making it bold if
the last command failed. I do it with:
# get "normal" and "emphasis" terminal entries
prompt_term[0]=$(tput sgr0)
prompt_term[1]=$(tput bold)
# make the prompt bold if the last command failed
PS1='\[${prompt_term[$(($??1:0))]}\]'"$PS1"'\[${prompt_term[0]}\]'
I will say though that getting into how the prompt looks can be highly
personalized bike-shedding. :) I haven't used the default Red Hat or
Fedora prompt basically ever IIRC (and I started with Red Hat with RHL
3.0.3, long before RHEL or Fedora).
--
Chris Adams <linux(a)cmadams.net>
12:36 p.m.
FWIW Haiku uses bash and has a prompt which changes colour
(green/red)
depending on whether the status code of the last command was good or
bad. I found this surprisingly useful. They use:
\[`if [ $? = 0 ]; then echo "\e[32m"; else echo "\e[31m";
fi`\]\w[\e[0m\]>
Warning: This is intrusive because reading the status code via "$?" resets it to
zero:
$ false
$ echo $?
1
$ echo $?
0
$
So a follow-on script cannot tell whether the command just before
the color-changing prompt succeeded or failed.
12:59 p.m.
Once upon a time, John Reiser <jreiser(a)bitwagon.com> said:
Warning: This is intrusive because reading the status code via
"$?" resets it to zero:
$ false
$ echo $?
1
$ echo $?
0
That is incorrect. The second reading of $? is the exit code of running
"echo $?" (which succeeded). Just reading the variable does not reset it.
$ false
$ echo $? $?
1 1
--
Chris Adams <linux(a)cmadams.net>
1:35 p.m.
On 5/22/23 10:59 AM, Chris Adams wrote:
Once upon a time, John Reiser <jreiser(a)bitwagon.com> said:
> Warning: This is intrusive because reading the status code via "$?" resets
it to zero:
> $ false
> $ echo $?
> 1
> $ echo $?
> 0
That is incorrect. The second reading of $? is the exit code of running
"echo $?" (which succeeded). Just reading the variable does not reset it.
$ false
$ echo $? $?
1 1
Also, $? doesn't change from commands in PS1 or PROMPT_COMMAND.
1:55 a.m.
On 5/22/23 16:42, Richard W.M. Jones wrote:
FWIW Haiku uses bash and has a prompt which changes colour
(green/red)
depending on whether the status code of the last command was good or
bad. I found this surprisingly useful. They use:
\[`if [ $? = 0 ]; then echo "\e[32m"; else echo "\e[31m";
fi`\]\w[\e[0m\]>
(or, as another example, just a fat red $? if it's != 0,
PS1='\[\e[0;1;31m\]${?#0}\[\e[30m\]\w \[\e[0m\]'
which I've gotten really dependent on over the years)
1:27 p.m.
On Sun, May 21, 2023 at 11:50 PM Jens-Ulrik Petersen
<petersen(a)redhat.com> wrote:
In Fedora the bash prompt is not colored or highlighted by default.
...
I think it would be nice to have a distinctive prompt by default, or
at least a very easy way to get one permanently (ie in a single command: even if that were
`dnf install bash-color-prompt` or running say `colorprompt` once).
We could put the following at the end of /etc/bashrc:
```
function _update_ps1() {
PS1="$(/usr/bin/powerline-go -modules
venv,user,host,ssh,cwd,perms,git,hg,jobs,exit -colorize-hostname
-error $? -static-prompt-indicator -newline -jobs $(jobs -p | wc -l))"
}
if [ "$TERM" != "linux" ] && [ -f
"/usr/bin/powerline-go" ]; then
PROMPT_COMMAND="_update_ps1; $PROMPT_COMMAND"
fi
```
See attached picture for what it looks like. I've been using this
setup on my machines for years and it's been super helpful. (Note that
the modules listed in the PS1 line there appear only when relevant. So
you won't see 'ssh', 'git', etc. information unless they're in
use.
1:28 p.m.
On Mon, May 22, 2023 at 2:27 PM Stephen Gallagher <sgallagh(a)redhat.com> wrote:
On Sun, May 21, 2023 at 11:50 PM Jens-Ulrik Petersen
<petersen(a)redhat.com> wrote:
>
> In Fedora the bash prompt is not colored or highlighted by default.
...
> I think it would be nice to have a distinctive prompt by default, or at least a very
easy way to get one permanently (ie in a single command: even if that were `dnf install
bash-color-prompt` or running say `colorprompt` once).
We could put the following at the end of /etc/bashrc:
```
function _update_ps1() {
PS1="$(/usr/bin/powerline-go -modules
venv,user,host,ssh,cwd,perms,git,hg,jobs,exit -colorize-hostname
-error $? -static-prompt-indicator -newline -jobs $(jobs -p | wc -l))"
}
if [ "$TERM" != "linux" ] && [ -f
"/usr/bin/powerline-go" ]; then
PROMPT_COMMAND="_update_ps1; $PROMPT_COMMAND"
fi
```
See attached picture for what it looks like. I've been using this
setup on my machines for years and it's been super helpful. (Note that
the modules listed in the PS1 line there appear only when relevant. So
you won't see 'ssh', 'git', etc. information unless they're in
use.
I hit "send" too soon. The configuration in /etc/bashrc will do
nothing until and unless the user installs the `powerline-go` package
(or we decide to ship it by default).
1:44 p.m.
Once upon a time, Stephen Gallagher <sgallagh(a)redhat.com> said:
We could put the following at the end of /etc/bashrc:
Something like that would seem more appropriate in an /etc/profile.d
drop-in - very little special-sauce should go in /etc/bashrc.
My personal (bike-shedding) preference is to not run external commands
on every prompt though; when a system is slow or having problems, those
can kill any chance at recovery or even troubleshooting.
--
Chris Adams <linux(a)cmadams.net>
1:59 p.m.
On Mon, May 22, 2023 at 2:44 PM Chris Adams <linux(a)cmadams.net> wrote:
Once upon a time, Stephen Gallagher <sgallagh(a)redhat.com>
said:
> We could put the following at the end of /etc/bashrc:
Something like that would seem more appropriate in an /etc/profile.d
drop-in - very little special-sauce should go in /etc/bashrc.
Sure, it just didn’t occur to me. Good idea.
My personal (bike-shedding) preference is to not run external commands
on every prompt though; when a system is slow or having problems, those
can kill any chance at recovery or even troubleshooting.
Sure, so just don’t install powerline-go and nothing runs per-prompt.
12:33 p.m.
Chris Adams wrote:
My personal (bike-shedding) preference is to not run external
commands
on every prompt though; when a system is slow or having problems, those
can kill any chance at recovery or even troubleshooting.
I agree. Please keep the number of things that can make the shell
unusable minimal.
Björn Persson
2:49 p.m.
On 22 May 2023, at 04:50, Jens-Ulrik Petersen
<petersen(a)redhat.com> wrote:
In Fedora the bash prompt is not colored or highlighted by default.
I personally find this a usability issue: it makes it hard to find previous commands
between long outputs when scrolling back in a terminal. Of course in my own host I have a
custom prompt, but it means whenever I am using a different Fedora/Centos/RHEL system or
vm, the prompt is not highlighted by default, which I miss.
Since I spent a little time thinking about and investigating this I thought I would write
to start a discussion here.
I noticed that Ubuntu has a bold green and blue prompt and NixOS has a green one by
default, though not Archlinux or OpenSuSE I think.
I think it would be nice to have a distinctive prompt by default, or at least a very easy
way to get one permanently (ie in a single command: even if that were `dnf install
bash-color-prompt` or running say `colorprompt` once).
For example I could suggest we change the default fedora bash prompt from:
PS1="[\u@\h \W]\\$ "
to something like:
PS1="\[\e[\${PROMPT_COLOR}m\][\u@\h \W]\[\e[0m\]\\$ ".
Then the PROMPT_COLOR envvar would make it easy for users to change or customize their
prompt coloring anyway.
For example with PROMPT_COLOR="1;32" one gets a bold green prompt, which seems
readable in both dark or light terminals.
What do people think overall? Are there other pros and cons of a color prompt?
Any better ideas or direction?
So long as you do this in such a way that if i set PS1 you do not override my config.
please do not set PROMPT_COMMAND either.
Barry
Jens
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
12:24 a.m.
Also while we are bike-shedding... What about \W vs \w ?
I think fedora has used \W "forever" - I am not a huge fan...
though I suppose its main merit is not over-flowing/extending for very long
dir paths.
Jens
9:46 a.m.
Once upon a time, Jens-Ulrik Petersen <petersen(a)redhat.com> said:
Also while we are bike-shedding... What about \W vs \w ?
I think fedora has used \W "forever" - I am not a huge fan...
though I suppose its main merit is not over-flowing/extending for very long
dir paths.
I use \w and set PROMPT_DIRTRIM=4.
--
Chris Adams <linux(a)cmadams.net>
5:25 a.m.
On 22/05/2023 05:49, Jens-Ulrik Petersen wrote:
What do people think overall? Are there other pros and cons of a
color
prompt?
Any better ideas or direction?
PS1 from all my systems:
export PS1="\[\e[33m\][\[\e[36m\]\u\[\e[0m\]@\[\e[31m\]\h\[\e[0m\]
\[\e[32m\]\W\[\e[33m\]]\[\e[35m\]\$\[\e[0m\] "
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
6:10 a.m.
> What do people think overall? Are there other pros and cons of a
color prompt?
> Any better ideas or direction?
I like the idea of using tput to get the correct strings for
setting different terminal effects, so I now use:
# Success prompt:
prompt_term[0]=$(tput bold)
# Fail prompt:
prompt_term[1]=$(tput setaf 1) # red
# Turn off all attributes
prompt_term[2]=$(tput sgr0)
# Make the prompt reflect the exit status of the last command
export
PS1='\[${prompt_term[$(($??1:0))]}\]'"\w"'\[${prompt_term[2]}\]'"
==> "
Cheers
Nick
8:21 a.m.
One of the things I discovered playing with tput last night trying
some of this is that it will error if you don't have a terminal.
ssh foo.example.com virsh start bar
tput: No value for $TERM and no -T specified
To correct this using your example you can do:
if [ -t 0 ]
then
prompt_term[0]=$(tput bold)
prompt_term[1]=$(tput setaf 1) # red
prompt_term[2]=$(tput sgr0)
export
PS1='\[${prompt_term[$(($??1:0))]}\]'"\w"'\[${prompt_term[2]}\]'"
==> "
fi
On Tue, May 23, 2023 at 7:10 AM Nick Clifton <nickc(a)redhat.com> wrote:
>> What do people think overall? Are there other pros and cons of a color prompt?
>> Any better ideas or direction?
I like the idea of using tput to get the correct strings for
setting different terminal effects, so I now use:
# Success prompt:
prompt_term[0]=$(tput bold)
# Fail prompt:
prompt_term[1]=$(tput setaf 1) # red
# Turn off all attributes
prompt_term[2]=$(tput sgr0)
# Make the prompt reflect the exit status of the last command
export
PS1='\[${prompt_term[$(($??1:0))]}\]'"\w"'\[${prompt_term[2]}\]'"
==> "
Cheers
Nick
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
--
Jason Montleon | email: jmontleo(a)redhat.com
Red Hat, Inc. | gpg key: 0x069E3022
Cell: 508-496-0663 | irc: jmontleo / jmontleon
9:48 a.m.
Once upon a time, Jason Montleon <jmontleo(a)redhat.com> said:
One of the things I discovered playing with tput last night trying
some of this is that it will error if you don't have a terminal.
ssh foo.example.com virsh start bar
tput: No value for $TERM and no -T specified
My prompt manipulations are wrapped in a test like:
if [ "$PS1" ]; then
<do stuff here>
fi
PS1 is not set on a non-interactive shell (no TTY assign), so don't do
anything to manipulate it if it isn't already set to something.
--
Chris Adams <linux(a)cmadams.net>
12:31 p.m.
Jens-Ulrik Petersen wrote:
In Fedora the bash prompt is not colored or highlighted by default.
I personally find this a usability issue: it makes it hard to find previous
commands between long outputs when scrolling back in a terminal.
I find myself pressing Enter several times before running a command to
be able to find the beginning of the output afterwards, so I agree. The
prompt should stand out more.
For example I could suggest we change the default fedora bash prompt
from:
PS1="[\u@\h \W]\\$ "
to something like:
PS1="\[\e[\${PROMPT_COLOR}m\][\u@\h \W]\[\e[0m\]\\$ ".
Then the PROMPT_COLOR envvar would make it easy for users to change or
customize their prompt coloring anyway.
For example with PROMPT_COLOR="1;32" one gets a bold green prompt, which
seems readable in both dark or light terminals.
It seems popular among terminal emulators to make bold text extra
bright. That makes the bold green prompt a bit too bright for me on a
white background. It's nowhere near as bad as yellow on white, but a
little too bright to be comfortable. Once I turn off the brightening to
let bold text be the specified color, the bold green prompt works well
for me.
One way to avoid all the color issues could be to just make the prompt
bold by default. That would probably make it stand out enough in many
situations. I think it wouldn't help much for programmers compiling
software though, because GCC outputs filenames in uncolored bold text,
so even a bold prompt would blend in among the compilation errors.
Björn Persson
1:45 p.m.
On Fri, 26 May 2023, Björn Persson wrote:
One way to avoid all the color issues could be to just make the
prompt
bold by default. That would probably make it stand out enough in many
situations. I think it wouldn't help much for programmers compiling
software though, because GCC outputs filenames in uncolored bold text,
so even a bold prompt would blend in among the compilation errors.
Underlining or reverse video would get my vote, instead of bold.
For myself, I have a more complicated scheme that sets the prompt background colour to
light grey on light terminals and dark grey on dark terminals. I find this is just enough
to easily find the prompt when scrolling back, without distracting from the output I’m
looking at. My instinct is that detecting the background colour too fiddly to inflict on
users by default, though.
--
Peter Oliver
10 p.m.
Late follow-up...
On Tue, May 30, 2023 at 2:46 AM Peter Oliver <
lists.fedoraproject.org(a)mavit.org.uk> wrote:
On Fri, 26 May 2023, Björn Persson wrote:
> One way to avoid all the color issues could be to just make the prompt
> bold by default. That would probably make it stand out enough in many
> situations. I think it wouldn't help much for programmers compiling
> software though, because GCC outputs filenames in uncolored bold text,
> so even a bold prompt would blend in among the compilation errors.
Right, true
Underlining or reverse video would get my vote, instead of bold.
I did play with reverse video before my original post, and found it rather
"high contrast" - though it may deserve more exploration.
Dim reverse video seems more palatable perhaps.
For myself, I have a more complicated scheme that sets the prompt
background colour to light grey on light terminals and dark grey on dark
terminals. I find this is just enough to easily find the prompt when
scrolling back, without distracting from the output I’m looking at. My
instinct is that detecting the background colour too fiddly to inflict on
users by default, though.
Yes, setting the background and foreground together is probably the safest
way to maintain good contrast.
Jens
10:32 a.m.
So I made a copr repo PoC:
https://copr.fedorainfracloud.org/coprs/petersen/bash-color-prompt/
which you can test: the bash-color-prompt package there drops a
conditionalized PS1 into /etc/profile.d/ for now.
$ sudo dnf-3 copr enable petersen/bash-color-prompt
$ sudo dnf install bash-color-prompt
This shouldn't really be the final solution though - I would like it to be
available by default (even if turned off), but at least this allows more
user-testing now in different scenarios.
The prompt is similar to the one from my original post and can still be
"user-themed" with PROMPT_COLOR: it now defaults to normal green and adds the
red error code from Stephan (maybe this part could still be improved?) -
both now non-bright/bold.
https://copr-dist-git.fedorainfracloud.org/cgit/petersen/bash-color-promp...
I can create a proper github or even pagure repo later if needed, but right
now I feel it would be helpful to have more user-feedback first.
I am happy to adapt this into a F39 Change (it could be monochrome by
default if pre-installed) if people want that: I feel it is only really
compelling if integrated into default desktop installations in some form.
Jens
ps It would be nice to support toolbox/containers too (like $debian_chroot) and
have opt-in for git branch too, but those could be added later I think.
Also a root color perhaps, as discussed.
pps I did test dim reverse-video but it looks quite stark in a light
terminal.
6:25 a.m.
Jens-Ulrik Petersen wrote:
it now defaults to normal green and adds the
red error code from Stephan (maybe this part could still be improved?)
I like the red error code enough that I'm trying it out on my own
workstation. Yet I doubt it's suitable for the default prompt. I'll
remember what it means because I've configured it myself. To a beginner
who hasn't configured their prompt, the intermittent appearance of a
red number will be very cryptic.
If the error code is included, then appending it to the working
directory isn't the best choice. It looks like a part of the directory
name, especially to red/green blind users I expect. There should be a
space or other separator, but even then it could be ambiguous as
filenames can contain almost any characters. Writing the error code
before the username is less confusing. Users are unlikely to think that
the digits are part of their username.
This code expands to nothing if the exit code is zero, and to the exit
code followed by a space otherwise:
prompt_result_separator=' '
PS1='\[\e[0;31m\]${?#0}\[\e[0m\]${prompt_result_separator[!$?]}...'
Note also the "0;" in the beginning. I think all prompts should begin
with that to clear any attributes that may have been left behind by a
broken program. (Try "echo -e '\e[8m'" and see if it hides your
prompt.)
Björn Persson
5:11 a.m.
Should this also take into account some common individual prompts?
We have for instance /usr/share/git-core/contrib/completion/git-prompt.sh sourced.
Maybe a form of compat for such wide used customisations? Thought ...
1:33 p.m.
I love the idea of a colorized prompt by default on Fedora!
A few points to the posted example:
- Let's keep it somewhat identical to the existing one unless a change is really
important
- Let's leave out the RC code from the prompt - that can be useful in certain
scenarios, but is distracting/annoying most of the time
- Keep the path part of the prompt a different color
Something like this perhaps, which is close to the current prompt, only with the addition
of useful colors. I personally like the default colors here too, because they work well:
PROMPT_COLOR=""
PROMPT_PATH_COLOR=""
PS1="[\[\e[${PROMPT_COLOR:-1;32}m\]\u@\h\[\e[0m\]
\[\e[${PROMPT_PATH_COLOR:-1;34}m\]\w\[\e[0m\]]\$ "
Cheers
307
days inactive
355
days old
44 comments
26 participants
participants (26)
-
Barry -
Ben Beasley -
Björn Persson -
Chris Adams -
Chris Murphy -
Dan Čermák -
David Cantrell -
DJ Chase -
Dridi Boukelmoune -
Jason Montleon -
Jens-Ulrik Petersen -
John Reiser -
Josh Stone -
Kushal Das -
Leon Fauster -
Marián Konček -
Mattia Verga -
Neal Gompa -
Nick Clifton -
Peter Oliver -
Richard W.M. Jones -
stan -
Stephan Bergmann -
Stephen Gallagher -
Thomas M Steenholdt -
Vitaly Zaitsev