Re: colorls in base
On 17.02.2019 05:52, John Nemeth wrote: > On Feb 17, 12:52am, Kamil Rytarowski wrote: > } On 16.02.2019 20:50, John Nemeth wrote: > } > I'm not a no changenik. However, I think change needs to have > } > demonstrated value. I do oppose change when it is done for the > } > sake of change. To me, fluff is not demonstrated value, especially > } > when you consider our market segmen > } > } That has been explained that colors ship information that cannot be > } encoded in a different way on a terminal and has to be prompted with > } different commands, tools or arguments to utilities. > > Nonsense. > Rationale? signature.asc Description: OpenPGP digital signature
Re: colorls in base
On Feb 17, 12:52am, Kamil Rytarowski wrote: } On 16.02.2019 20:50, John Nemeth wrote: } > I'm not a no changenik. However, I think change needs to have } > demonstrated value. I do oppose change when it is done for the } > sake of change. To me, fluff is not demonstrated value, especially } > when you consider our market segmen } } That has been explained that colors ship information that cannot be } encoded in a different way on a terminal and has to be prompted with } different commands, tools or arguments to utilities. Nonsense. } We resist also personal taste but aesthetics is also important for } many/most(?) people. For the some reason probably nobody deliberately } watches black-white TV and old valuable movies are now often painted. Many people consider this to be ruining them. }-- End of excerpt from Kamil Rytarowski
Re: colorls in base
On 17.02.2019 01:51, Paul Goyette wrote: > On Sun, 17 Feb 2019, Joerg Sonnenberger wrote: > >> ... In this case, the color doesn't take anything away from >> you. You are no worse off than before, e.g. you have to run additional >> commands or long format to figure out what are subdirectories etc. > > Not entirely true. > My rationale for keeping it by default disabled is to support well various ports that might have different / custom colors in terminals, such as macppc that uses wite background and black text. Printing yellow letters is readable on black background, but problematic on white. signature.asc Description: OpenPGP digital signature
Re: colorls in base
On Sun, 17 Feb 2019, Joerg Sonnenberger wrote: ... In this case, the color doesn't take anything away from you. You are no worse off than before, e.g. you have to run additional commands or long format to figure out what are subdirectories etc. Not entirely true. For those of use with red-green protanopic (?) color-blindness, we have a deficiency in "red cones" which reduces the ability to distinguish red from black. Red text would disappear on a black background. +--+--++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: colorls in base
On 16.02.2019 20:50, John Nemeth wrote: > I'm not a no changenik. However, I think change needs to have > demonstrated value. I do oppose change when it is done for the > sake of change. To me, fluff is not demonstrated value, especially > when you consider our market segmen That has been explained that colors ship information that cannot be encoded in a different way on a terminal and has to be prompted with different commands, tools or arguments to utilities. We resist also personal taste but aesthetics is also important for many/most(?) people. For the some reason probably nobody deliberately watches black-white TV and old valuable movies are now often painted. signature.asc Description: OpenPGP digital signature
Re: colorls in base
On Fri, Feb 15, 2019 at 05:58:36PM +0100, Christian Groessler wrote: > On 2/15/19 3:20 PM, Christos Zoulas wrote: > > The kernel is already using green, and recently we added "autoconfiguration > > error" to highlight errors. Shouldn't we (in addition) make those lines red? > > > Please not. Red (esp. dark read) will be difficult to read for me. I'm color > blind. I find that argument strange. The normal cases of color "blindness" I know make it difficult to *distingiush* colors. The most common case being the red/green blindness that good chunk of the male population enjoys. That just means that color shouldn't be the only way to encode information. In this case, the color doesn't take anything away from you. You are no worse off than before, e.g. you have to run additional commands or long format to figure out what are subdirectories etc. Joerg
Re: colorls in base
On 16.02.2019 18:30, Robert Elz wrote: > They haven't yet, but eventually will. Sometime, if this was added, > someone will say "Why don't we enable colours from ls by default, just > like all the other OS's do? We have the code already, all we need to do > is turn it on." That's almost guarranteed to happen. I fully support this to add COLORTERM definition to sysinst(8) and we can solve this doubt proactively. Personally I will keep enabling it. signature.asc Description: OpenPGP digital signature
Re: colorls in base
On Feb 17, 12:30am, Robert Elz wrote:
}
} Date:Sat, 16 Feb 2019 15:02:58 - (UTC)
} From:chris...@astron.com (Christos Zoulas)
} Message-ID:
}
} What I do replace from base (every time) is postfix (by sendmail).
} Somehow I doubt that a request to stick sendmail back in base is
} going to get very far.
I would support it. :-) But, I agree with you that it would
be pretty pointless to make the proposal. You would get a crap
ton of people jumping up and down, screaming stuff about security,
even with:
i386devel: {169} cvs up pkg-vulnerabilities
M pkg-vulnerabilities (the local mods are all related to Asterisk)
i386devel: {170} grep -ic sendmail pkg-vulnerabilities
15
i386devel: {171} grep -ic postfix pkg-vulnerabilities
18
Some will argue about ease of configuration and this can certainly
be a valid argument. I've been configuring sendmail since the late
'80s, i.e. before the M4 days. I also make extensive use of
milters. With postfix, I know enough to get it to forward to a
smart mailer, which will be sendmail. I don't know how to configure
it to do the stuff that I do with sendmail. However, I do recogonise
that having a simple well commented config file will be easier for
most people, especially those that don't have highly complex special
situations.
} | As features become standard to other OS's we should evaluate if
} | we should follow suit.
}
} That's reaosnable. But "XYZ has it, so so should we" or "XYZ has it
} and I like it" are not reasons - what we need to discover is what we
} are missing (what we cannot achieve) without it. or what is much
} harder. If something adds some ability that is either lacking, or
} very difficuly to achieve any other way, then sure, we should add it.
} If all it would achieve is making NetBSD look the same as XYZ, then
} we should not.
+1
} ps: Also in this discussion there has been menytion of "ls -F". I had
} always assumed that we had that utter crud only because POSIX says that
} it is required, I never imagined that anyone would actually use that
} nonsense. Eg:
}
} jinx$ ls -F
} x* y*
}
} What do you deduce from that? If you thing there are two files, x and
} y, and they're both executable, then, sorry, you're wrong. But even
} with that knowledge, what do you know now? Anything at all? I very
} much doubt it (except that there are two files in '.'). The only part
} of ls -F that works, is the '/' to indicate directories, but that's
} not needed, as "ls -d */." or just "echo */." work to tell you what
} sub-dirs exist in the current directory (and do it better).
}
} Whever designed that option (the way that it works) is a cretin.
}
} The way to find out what kind of things exist in a directory is to use
} ls -l and look at the mode bits, or use stat - or write a simple script
} to use one of those (or find) to extract whatever info you actually need,
} which will almost certainly be different than what I need. It has been
} that way since the early Bell Labs versions, and nothing anyone has ever
} done t attempt to make it better, or easier (in any environment) has
} achieved either of those goals, as best I can tell. Nothing.
Wow! Quite the rant. I use ls -F all the time and find it
to be very useful. I've been using it since I first touched a
unix-like system somewhere in the late '80s. The alternatives that
you mention certainly work, but are more cumbersome. I agree that
they may be needed in some situations as they are more "authoritative".
After all, there is nothing stopping somebody from naming a regular
file "x*", which would be quite annoying, since the only characters
that can't appear in a file name are "/" and "(null)".
What is interesting about this rant is that many people use
colorls to do what "ls -F" does (i.e. distinguish regular files
from directories and executables). This means that your rant mostly
applies to colorls as well, except that colorls won't mix up regular
file "x*" with executable file "x". However, since I don't know
what the different colours mean (and they would disappear if I send
the output to a pipe/file) they convey absolutely no useful
information to me (and likely many others not coming from a certain
environment).
On a side note, I once had an issue with a "/" appearing in
a filename. It was on a system that acted as an NFS server to
Macs. MacOS used ":" as the directory separator so "/" was allowed.
This was obviously a bug in the NFS server software. I ended up
using cleari followed by fsck to get rid of that nasty little thing.
It was probably the only time that I used cleari.
}-- End of excerpt from Robert Elz
Re: colorls in base
On Feb 16, 3:02pm, Christos Zoulas wrote: } In article <20190216102435.ga10...@grapefruit.pr0.tips>, } Timo Buhrmester wrote: } >> All I know is that some directories look like an "explosion in a } >> paint factory" or "angry fruit salad". } >I wonder why the die-hard monochrome users keep arguing from a } >"but it isn't pretty" point of view. It's not supposed to be pretty, } >it's supposed to augment the information presented. } > } >> The colours convey absolutely no information to me. I need to use } >> other information to figure out what the colours are trying to tell } >> me. } >And that's fine and how it's supposed to be. The colors helped drawing } >your attention to it quickly. I don't think anybody here is arguing } >that colors would directly encode high-level diagnostic information. } > } > } >To the color-blind people, I get it, it's counter productive for you. } >However I don't get the feeling that anybody is trying to enable } >colors unconditionally, or by default even. I also have issues with } >the "I can't tell apart colors, so nobody may use colors" mindset. } > } >We shouldn't put up artificial barriers for color-blind people (nor any } >other disability), which in this case would mean "colors, if present, } >shouldn't be enabled by default" (that said, our installer is blue...) } >but that's about the extent of it IMHO. } } Yes, what I don't understand (because nobody has stated a technical } reason other than 'fluff'), why we shouldn't we have the feature in base } at all. Nobody proposed to enable it by default. As features become } standard to other OS's we should evaluate if we should follow suit. I consider this to be a good reason. We shouldn't be adding fluff just so that we can keep up with the Joneses. } Things change over time; we don't go rip out color output compiler } support from the compilers. It is not enabled by default so it is } invisible. So will be having color in some programs in base. It will } be invisible unless you specifically turn it on. I'm not a no changenik. However, I think change needs to have demonstrated value. I do oppose change when it is done for the sake of change. To me, fluff is not demonstrated value, especially when you consider our market segment. } It is not frictionless (and should be but that's another issue) to } "install from pkgsrc" and it's a good question why not have the feature You're right, that's a different question. If it is really problem, then it needs solving, independently of any other question. } in base when the majority of the users just install replacements from } pkgsrc because of the lack of features. It is not 1980 anymore and Who is this "majority" of which you speak? I haven't take a count, but it feels to me that there are less then a dozen people participating in this thread (some of whom are very vocal). } we don't need to be frugal about resources (specially when they can } be compiled out). Compiling out stuff is not free. It takes disk space and large amounts of admin time for on-going maintenance. }-- End of excerpt from Christos Zoulas
Re: colorls in base
On Feb 16, 12:42pm, Timo Buhrmester wrote: } } > Prettiness is the last thing that concerns me, cloaking information with } > gleeful colorized flashlights and blinding me with candy colored dots is. } Sorry, I wasn't aware how messed up cognition can be. Which color } is the most blinding to you? Does the 'cloaking' aspect increase or } decrease with the increase/decrease in intensity/brightness, for } information printed in that particular color? I fail to see how it is possible for people to so completely not "get it". } > You may use colors all day long, it's as simple as installing a color-ls } > program. } That has already been established and is besides the point here. No, it is completely the point. People that want this kind of stuff can easily get it without corrupting the base system. }-- End of excerpt from Timo Buhrmester
Re: colorls in base
> On Feb 16, 2019, at 12:30 PM, Hauke Fath > wrote: > > I remember you speaking up against replacing csh(1) with tcsh in base a few > years ago. How about adding tcsh's complete facility to csh(1)? That is > probably an order of magnitude in codesize compared to ls(1) vs. > colo(u)rls, but I see a moral equivalent. I mentioned back then a few reasons: 1. our csh uses stdio and does not require a custom printf etc. 2. tcsh has a built-in copy of libedit which has a complicated relationship with the shell. 3. the csh code is much cleaner and simpler. 4. tcsh has a lot of OS compatibility code that is mixed in with the code that's not needed for NetBSD On the opposite side: 1. tcsh has many more features and the integrated editor and completion work very well together. 2. csh leaks memory on errors where the new tcsh unwind code handles memory allocation much better. >> So will be having color in some programs in base. It will >> be invisible unless you specifically turn it on. > > I guess some of us see a slippery slope? Yes, and this fear is causing unnecessary conservatism in this case. You can fight changing the default later, and even claim "I told you". Also who knows, if we build this feature well, maybe even some of the people who oppose it will like it. BTW I personally don't currently use any color in my screen because I am used to my way of working, and I don't find it useful. This is a personal preference though, and I can see that others might find it useful or even just like it. > > Careful, that way lie bash and emacs, cups and ... Yes, and sometimes we need to carefully think about the advantages and disadvantages maintaining our own copies of everything. There are costs and benefits either way. But those again might shift over time. For example, in make(1) we don't have pattern rules and this has slowly eroded our ability to use our make(1) in pkgsrc. Or autoconf using LINENO has forced that in our shell, and autoconf again using m4 features our m4 did not support forced us to add them. > >> It is not 1980 anymore and >> we don't need to be frugal about resources (specially when they can >> be compiled out). > > Well, we still support most of the architectures we supported in the > mid-nineties (and even vax from the eighties). So it would be nice if base > ran reasonably well on them. Yes, and we still do run pretty well considering. We can't build in some of them because of compiler bloat, but the efforts to support a leaner compiler have not panned out. For the specific colorls example, we could consider turning the feature off on slower/smaller archs, but I don't think this is necessary. christos
Re: colorls in base
At 15:02 Uhr + 16.02.2019, Christos Zoulas wrote: >Yes, what I don't understand (because nobody has stated a technical >reason other than 'fluff'), ... I guess that hurt. It wasn't meant to, sorry, just a tongue-in-cheek handle to a serious point. > why we shouldn't we have the feature in base at all. I remember you speaking up against replacing csh(1) with tcsh in base a few years ago. How about adding tcsh's complete facility to csh(1)? That is probably an order of magnitude in codesize compared to ls(1) vs. colo(u)rls, but I see a moral equivalent. >Things change over time; we don't go rip out color output compiler >support from the compilers. It is not enabled by default so it is >invisible. We don't, because needless deviating from upstream source incurs high maintenance cost, and is frowned upon. >So will be having color in some programs in base. It will >be invisible unless you specifically turn it on. I guess some of us see a slippery slope? >It is not frictionless (and should be but that's another issue) to >"install from pkgsrc" and it's a good question why not have the feature >in base when the majority of the users just install replacements from >pkgsrc because of the lack of features. Careful, that way lie bash and emacs, cups and ... > It is not 1980 anymore and >we don't need to be frugal about resources (specially when they can >be compiled out). Well, we still support most of the architectures we supported in the mid-nineties (and even vax from the eighties). So it would be nice if base ran reasonably well on them. Cheerio, hauke -- "It's never straight up and down" (DEVO)
Re: colorls in base
At 19:47 Uhr + 15.02.2019, m...@netbsd.org wrote:
>I for one am quite fed up with how I have to replace around 30% of base
>to get a usable setup.
Yes. We've all been there, and I feel your pain.
> my set of substitutions are:
>
>- g95 -> gfortarn, because we don't default to modern fortran.
>- xsrc -> modular xorg, because I want graphical acceleration to work
> and old OpenGL isn't good
>- default modular xorg fonts -> noto-ttf, dejavu-ttf
>- change default console font to a readable one (firacode for me)
>- default wm not being a usable option
>- manually configure HiDPI because it isn't automatically detected
Now, I don't care about any of the above, except for the X11 window
manager. And I won't list my standard replacements, because you (or anybody
else) would not care about them in return.
Because people's sets of preferred tools don't intersect much, the powers
that be conceived pkgsrc.
>I can't hand netbsd to a stranger because I can't expect them to make
>the same substitutions themselves.
sysinst offers installing pkgin. Have them install their preferred tool
packages (maybe we should have "meta/linux-look-and-feel"?), prefix PATH
with ${LOCALBASE}/{s,}bin, und fertig ist der Lack*.
Cheerio,
hauke
(*) "Bob's yer uncle."
--
"It's never straight up and down" (DEVO)
Re: colorls in base
Date:Sat, 16 Feb 2019 15:02:58 - (UTC) From:chris...@astron.com (Christos Zoulas) Message-ID: | Yes, what I don't understand (because nobody has stated a technical | reason other than 'fluff'), why we shouldn't we have the feature in base | at all. Nobody proposed to enable it by default. They haven't yet, but eventually will. Sometime, if this was added, someone will say "Why don't we enable colours from ls by default, just like all the other OS's do? We have the code already, all we need to do is turn it on." That's almost guarranteed to happen. If you (and everyone else, including the THF board, and core) will agree that as soon as someone suggests this, that colour support would immediately be removed from ls again, then I would have less problems with it... Personally, I don't see any big difference between "install from pkgsrc" (for a simple program, as distinct from some part of one of the monsters) compared with doing some configuration setup - in fact, for naive users, one could say that installing from pkgsrc is likely to be easier, particularly as they're going to be doing it for all kinds of other things as well (unless we start shipping all kinds of other stuff, browsers (a choice thereof) PDF viewers (same) image viewers (same) video players (same) ...) Note that whatever one might think, a simple "-X turns on colours" is not going to work. Something has to determine which colours get used, and that cannot really be a constant, as what works depends upon the user's terminal foreground and background colours, and, at least as much as I know about this stuff, there's no reasonable way for a program like ls to discover what those are. That is, if ls decides that directories should be blue (which I think someone said that some colourising version of ls does) how does that work in a terminal with a blue background? Doing this properly is not at all easy. Doing it poorly is not something we ought to be aiming for, Personally, I believe that we ought to keep base to the basic set of programs that are needed to be able to use the system well enough to be able to install more, and not attempt to provide everything that anyone might ever want - and particularly not because some other OS does it that way. Being different can be a good thing - particularly when it is leaner and cleaner. A while ago in this "conversation" maya posted a liet of things that get replaced as part of the install -- that list only had one thing in common with me, the window manager. And while twm certainly isn't what almost anyone would pick, it still functions, and is enough to allow X to be used while installing something better. And of course this is a case where there's zero chance we'd ever come close to agreeing on what particular better replacement to include. What I do replace from base (every time) is postfix (by sendmail). Somehow I doubt that a request to stick sendmail back in base is going to get very far. The lesson from this, I think, is that different users have different needs and desires, and we cannot possibly meet all of them, and it would be unreasonable to pick some particular (especially controversial) functionality and add it, while not adding everything that everyone else wants as well. | As features become standard to other OS's we should evaluate if | we should follow suit. That's reaosnable. But "XYZ has it, so so should we" or "XYZ has it and I like it" are not reasons - what we need to discover is what we are missing (what we cannot achieve) without it. or what is much harder. If something adds some ability that is either lacking, or very difficuly to achieve any other way, then sure, we should add it. If all it would achieve is making NetBSD look the same as XYZ, then we should not. | Things change over time; we don't go rip out color output compiler | support from the compilers. Had I known it was there I might have. What a truly brain dead idea. It truly shocked me to read the "it enables eye balling to quickly find the error message" - has no-one ever learned anything? We have (nicely powerful) searching abilities that can do that much better, in much bigger output, much more quickly, and almost infinitely mroe accurately, than any form of human eye-balling will ever achieve, whatever assistance is added. Doing anything to make eye-balling to find stuff (whatever it might be) is pushing things in entirely the wrong direction. If anything we should be making that harder, not easier, top encourage proper use of the tools (and yes, even in a browser, you can search for text!) | "install from pkgsrc" and it's a good question why not have the feature | in base when the majority of the users just install replacements from | pkgsrc because of the lack of features. If we could demonstrate that for something in particular, then that might be a convincing argument. But I very much doubt that is true for co
Re: colorls in base
> Yes, what I don't understand (because nobody has stated a technical > reason other than 'fluff'), why we shouldn't we have the feature in base > at all. Nobody proposed to enable it by default. Thank you! I personally think it is unreasonable to oppose adding a default-disabled feature like this one because you won't use it for whatever reason. Would I use colored ls? Maybe. But if I don't like it, I won't enable it. -- Benny
Re: colorls in base
On 2019-02-15 21:47, Kamil Rytarowski wrote: > Colors nowadays are industry standard and increase readability. I dislike colored ls with a passion simply because each time I use a new Linux system, I can't see the very dark blue directory entries on black background (in particular if there are other brighter colors around). I asked about this on IRC years ago and they told me that people use gnome-terminal with a white background, and it works fine there (which indeed it does). That's the kind of thing that I'm afraid is going to happen here. I realize it's impossible to cater to everyone's tastes/needs, but that's the nice thing about the "monochrome" output -- it's the least common denominator; while not optimal for those who want colors, it doesn't hinder anyone from getting things done. Not being able to see directory entries, on the other hand, is a direct hindrance. I don't see why anyone would disagree with the proposal to add colorls disabled by default though. If the default color scheme doesn't suck, I'll even give it try myself. -- Kind Regards, Jan Danielsson
Re: colorls in base
In article <20190216102435.ga10...@grapefruit.pr0.tips>, Timo Buhrmester wrote: >> All I know is that some directories look like an "explosion in a >> paint factory" or "angry fruit salad". >I wonder why the die-hard monochrome users keep arguing from a >"but it isn't pretty" point of view. It's not supposed to be pretty, >it's supposed to augment the information presented. > >> The colours convey absolutely no information to me. I need to use >> other information to figure out what the colours are trying to tell >> me. >And that's fine and how it's supposed to be. The colors helped drawing >your attention to it quickly. I don't think anybody here is arguing >that colors would directly encode high-level diagnostic information. > > >To the color-blind people, I get it, it's counter productive for you. >However I don't get the feeling that anybody is trying to enable >colors unconditionally, or by default even. I also have issues with >the "I can't tell apart colors, so nobody may use colors" mindset. > >We shouldn't put up artificial barriers for color-blind people (nor any >other disability), which in this case would mean "colors, if present, >shouldn't be enabled by default" (that said, our installer is blue...) >but that's about the extent of it IMHO. Yes, what I don't understand (because nobody has stated a technical reason other than 'fluff'), why we shouldn't we have the feature in base at all. Nobody proposed to enable it by default. As features become standard to other OS's we should evaluate if we should follow suit. Things change over time; we don't go rip out color output compiler support from the compilers. It is not enabled by default so it is invisible. So will be having color in some programs in base. It will be invisible unless you specifically turn it on. It is not frictionless (and should be but that's another issue) to "install from pkgsrc" and it's a good question why not have the feature in base when the majority of the users just install replacements from pkgsrc because of the lack of features. It is not 1980 anymore and we don't need to be frugal about resources (specially when they can be compiled out). christos
Re: colorls in base
> To me it's the gloriously colorful that keep arguing that other people > argue "but it isn't pretty". Care to elaborate? > Prettiness is the last thing that concerns me, cloaking information with > gleeful colorized flashlights and blinding me with candy colored dots is. Sorry, I wasn't aware how messed up cognition can be. Which color is the most blinding to you? Does the 'cloaking' aspect increase or decrease with the increase/decrease in intensity/brightness, for information printed in that particular color? As for the blinding candy colored dots, while I'm not sure where you're seeing those, is the degree of blinding related to their size or their frequency, or variance in color? Are subpixel errors on color displays on the 'most tolerable' or on the 'most blinding' end of the spectrum? Do you get an afterimage when looking away after staring at a blinding colorful dot for a few seconds? > If I wanted marketing, I'd replace shell output with a web site. How's marketing related to this? Color == marketing? > You may use colors all day long, it's as simple as installing a color-ls > program. That has already been established and is besides the point here. > Next time it's not about colorized output but some other feature of > "program found somewhere else". According to some we already have to > replace 30% of NetBSD to make it usuable, a measly colorized ls won't > be enough. I've rarely seen this many logical fallacies condensed into one short email. Hats off to you.
Re: colorls in base
fstd.l...@gmail.com (Timo Buhrmester) writes: >colors unconditionally, or by default even. I also have issues with >the "I can't tell apart colors, so nobody may use colors" mindset. You may use colors all day long, it's as simple as installing a color-ls program. Next time it's not about colorized output but some other feature of "program found somewhere else". According to some we already have to replace 30% of NetBSD to make it usuable, a measly colorized ls won't be enough. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: colorls in base
fstd.l...@gmail.com (Timo Buhrmester) writes: >I wonder why the die-hard monochrome users keep arguing from a >"but it isn't pretty" point of view. It's not supposed to be pretty, >it's supposed to augment the information presented. To me it's the gloriously colorful that keep arguing that other people argue "but it isn't pretty". Prettiness is the last thing that concerns me, cloaking information with gleeful colorized flashlights and blinding me with candy colored dots is. If I wanted marketing, I'd replace shell output with a web site. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: colorls in base
> All I know is that some directories look like an "explosion in a > paint factory" or "angry fruit salad". I wonder why the die-hard monochrome users keep arguing from a "but it isn't pretty" point of view. It's not supposed to be pretty, it's supposed to augment the information presented. > The colours convey absolutely no information to me. I need to use > other information to figure out what the colours are trying to tell > me. And that's fine and how it's supposed to be. The colors helped drawing your attention to it quickly. I don't think anybody here is arguing that colors would directly encode high-level diagnostic information. To the color-blind people, I get it, it's counter productive for you. However I don't get the feeling that anybody is trying to enable colors unconditionally, or by default even. I also have issues with the "I can't tell apart colors, so nobody may use colors" mindset. We shouldn't put up artificial barriers for color-blind people (nor any other disability), which in this case would mean "colors, if present, shouldn't be enabled by default" (that said, our installer is blue...) but that's about the extent of it IMHO.
Re: colorls in base
On Fri, 15 Feb 2019, m...@netbsd.org wrote: > sorry, I came here with a bit of an axe to grind. probably weshould not > make things hard to people who are color blind, when red/green color > blindness is so common. I just looked it up, this affects approximately 8% of european descent males according to wikipedia, less so for asians=>africans=>females. I did not know it was quite so common > i wonder if we can do anything about the shade of red/green for the > console too. It seems entirely reasonable, if colour is being used, to follow pallette guidelines such as this http://jfly.iam.u-tokyo.ac.jp/color/#pallet iain
Re: colorls in base
On Sat, 16 Feb 2019, Christian Groessler wrote: And, yes, in daily live, I can see and distinguish traffic lights. The only important thing in this regard... I actually have trouble at nighttime to tell the difference between the green traffic lights and other "white" lights. I actually used to check whether there was a different colored light above the green one, but that actually failed in some parts of Trenton NJ where the lights were mounted horizontally! I never could remember whether green was on the left or right! +--+--++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: colorls in base
On 2/16/19 7:14 AM, Anders Magnusson wrote: Don't know Debian, but at least Redhat: [ragge@beta ~]$ ls -l /etc/profile.d/colorls.csh -rw-r--r-- 1 root root 1741 30 jun 2016 /etc/profile.d/colorls.csh Ok. I'm seeing colorls.sh and colorls.csh in /etc/profile.d on a Fedora 27 box. My point was that it's not obvious how to turn it off. I'm not installing new systems on a daily, weekly, or even monthly base. It's always a hassle to find out to find out how exactly to turn it off. And won't deleting this file not make the "coreutils-common" package broken? # rpm -qf /etc/profile.d/colorls.csh coreutils-common-8.27-21.fc27.x86_64 # regards, chris
