Red Hat Bugzilla – Bug 817218
htm files not in DIR_COLORS
Last modified: 2012-05-04 06:35:18 EDT
Description of problem:
I am seeing that ls now colors text files brown. Cool. That being said, looking in /etc/DIR_COLORS shows that in the grouping "colorize basic documents (brown)" there is an entry for html but not one for htm.
Would be nice to have that (yes, I know I can edit the file, but I really prefer to use Fedora "as is" to the best of my ability.
Version-Release number of selected component (if applicable):
running F16 on i386/i686 under Xfce
kernal is 3.3.2-6
everything up-to-date as of 26apr12
don't know where to find out version for DIR_COLORS
Steps to Reproduce:
1. create a *.html and *.htm file
2. type "ls"
the html file will be brown, the htm will be black
both should be brown
I have no idea what component DIR_COLORS is in so I had to leave that empty.
I am not seeing this coloring on F14 (where all my machines used to live), so the change happened in F15 or F16.
I know this is kinda trivial in the grand scheme of things, but if someone took the time to add all these codings for text files I think is is fair for me to ask that he/she covers all of them.
Given the sharing of data between machines of different OS's, I don't think it is right to have to change all *.htm to *.html.
Let me know if I can give anymore information.
Thanks for report, an easy change in Fedora DIR_COLORS files. Please check your /etc/DIR_COLORS* files - and the last section. If you will find another textfile extension missing there, feel free to report it here - so I can add them together.
Note that this type of colorized files is not in upstream dircolors.hin color file - and brown color was chosen to match midnight commander color.
Thank you for the prompt turnaround.
I didn't spot any other missing extensions, but then again alot of the ones you did get are unknown to me. My usage is a subset, not a superset, of whats in DIR_COLORS. There were one or two "interesting decisions", but nothing worth bringing up.
I kinda like the brown as it is different but not overpowering. I'm just happy someone thought to put this in as I am finding it is really handy for quick scans of recursive ls's. It would be handy if DIR_COLORS not only mentioned the "color" that each ;3# is but give the closest html/htm color assignment (as in "#rrggbb" where each of the three ranges from 0x00 to 0xFF) ... brown is pretty subjective (smile).
I am assuming the note that it is targetted for rawhide means it won't make it into F16. Its such an easy edit that I'm not concerned. My one question is it looks like Rawhide is F18 ... would be nice to get it into F17 given that its not even released yet (sometime in May if I remember).
Taking a closer look at the DIR_COLORS, it seems as though it is designed for customization based on the comments. Looking online, I am seeing one can copy it to ~user/.dir_colors. Is there a way to have it look in ~user/.dir_colors and then /etc/DIR_COLORS so a user only has to keep changes/additions? It seems that only having .dir_colors would mean there could be no system changes by root or updates from yum (and/or a new Fedora release). Very low priority, but I thought I would ask as it kinda fits in with this bug for "how to best handle F16 and F17 (assuming Rawhide/F18 is the earliest your changes will make it).
Once again, my thanks for the prompt reading/assigned of the bug
About version: I'll fix it in rawhide and then in next coreutils cumulative update in F16/F17 (probably in one month or so). I don't want to make an update just for this to safe some internet bandwidth in common "not so small" package.
About ~/.dir_colors: Nice idea - but user modifications of the system defaults should be already possible with sourcing /etc/DIR_COLORS file at beginning of the ~/.dir_colors file (. /etc/DIR_COLORS ) - but I haven't tried that TBH.
Regarding version, what you suggest sounds great ... thanks!
Regarding ~./dir_colors, I just did a search and am not seeing anything online for DIR_COLORS which suggests that the ~/.dir_colors file can source another file. Do you know a link with more information on this? The best I am seeing is adding a test/eval inside the .bashrc which doesn't seem as clean a seperate ~/.dir_colors file (and I am not assured that any given user will be bash or tcsh or one of the other shells.
If there is no doc, then I need to check if you suggesting that the source command is literally ". /etc/DIR_COLORS"? Also, does the executing program bail once it finds a match, meaning if a user had his/her colors followed by sourcing the /etc/DIR_COLORS would use user color over system color (such as a user wanting text files to be something other than brown)?
You are right, that sourcing suggestion doesn't work ... sorry for that.
So probably implementing some kind of "include" keyword into dircolors.c might be useful for this usecase. I'll put that into my todo list.
Thanks for checking on the sourcing. I think your "something like include" suggestion is a good one. Do you want me to generate a new bug for this suggestion?
Yes, please, RFE against Rawhide... it will be harder to forget and easier to reference. Thanks in advance.
I have submitted as "Bug 818069 - suggestion for DIR_COLORS"
Please let me know if I need to modify or clarify the request
I just downloaded a html page and, while dealing with renaming it, I noticed that its extension is "*.shtml. Did a bit of googling and, though I can't see any reason why I wouldn't rename it to htm/html, it clearly is a valid txt format.
I've seen them before but didn't think about them when I wrote "I don't see anything else missing". I wanted to let you know so you can decide if there is something about shtml which would exclude it from ls coloring it "brown"
Commited to Rawhide git -> http://lists.fedoraproject.org/pipermail/scm-commits/2012-May/778409.html -> Closing RAWHIDE ... I'll update it in older Fedora's in next cumulative update.