Re: [PATCH 1/8] Import $LS_COLORS parsing code from coreutils

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Duy Nguyen <pclouds <at> gmail.com> writes:

> On Fri, Mar 21, 2014 at 2:09 AM, David Tran <unsignedzero <at> gmail.com>
wrote:
> > Nguyễn Thái Ngọc Duy <pclouds <at> gmail.com> writes:
> >
> >> This could could help highlight files in ls-files or status output, or
> >> even diff --name-only (but that's questionable).
> >>
> >> This code is from coreutils.git commit
> >> 7326d1f1a67edf21947ae98194f98c38b6e9e527 file src/ls.c. This is the
> >> last GPL-2 commit before coreutils turns to GPL-3.
> >>
> >
> > I don't know if this is something to consider but for my mac, I have another
> > variable CLICOLOR which shows the colors if it is set. This is also true
with
> > FreeBSD[1] as well. I don't know if that should be checked if you're on
those
> > systems.
> >
> > I think it would be nice to have --color flag as well if you want to enable
> > color output for just that one output.
> 
> My plan is stick to how git handles colors (e.g. --color and color.*
> config variables). Is that enough or do you think git CLICOLOR should
> override --color and color.*?
> 
I would say it is not an essential feature to have but something that might
be looked into once the color is implemented. If its not set, ignore it. If
it is set, check if it is truthy, is what I would do.




--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]