Skip to content

Highlight paths with colors from LS_COLORS? #605

@kbd

Description

@kbd

Recently came across this project that syntax-highlights file paths according to LS_COLORS. I already use zsh-syntax-highlighting; it would be nice if this feature could be included so I could use my LS_COLORS everywhere. Thanks. #feature-request

Activity

danielshahaf

danielshahaf commented on Mar 12, 2019

@danielshahaf
Member

Could you link to a specification of LS_COLORS that we can work off of?

kbd

kbd commented on Mar 12, 2019

@kbd
Author

Good question! GNU ls manpage says:

With --color=auto, ls emits color codes... The LS_COLORS environment variable can change the settings. Use the dircolors command to set it.

dircolors docs say:

For details on the format of these files, run ‘dircolors --print-database’.

I won't copy/paste that here. The author of that zsh filetypes syntax highlighting project I linked to has a repository with a large predefined LS_COLORS file. In that file he mentions that the extended color codes it uses are defined in ECMA-48. Otherwise, it looks like the output from dircolors --print-database is the closest thing to an actual specification there is.

I found this article documenting it as well. Otherwise, it looks like it doesn't actually take that much code to process (though unfortunately that code appears to be entirely without a license 🤦‍♂️, while his LS_COLORS repo has the Artistic license).

However, it appears to be a well-understood format. That askubuntu thread seems to be the best resource on it and that answer includes a simple script to dump all file types and their associated colors.

danielshahaf

danielshahaf commented on Mar 13, 2019

@danielshahaf
Member

First of all, thanks for the well-researched and well-presented answer.

As you probably know, there are copyright issues here. z-sy-h is BSD-licensed, so we can't use anything that's derived from askubuntu posts or from dircolors, as they are CC BY-SA- and GPL-licensed respectively. The output of dircolors --print-database, however, is excepted from the license of dircolors proper, through an explicit copyright notice it includes:

Copyright (C) 1996-2016 Free Software Foundation, Inc.
Copying and distribution of this file, with or without modification,
are permitted provided the copyright notice and this notice are preserved.

I'm not sure how to interpret that; it gives permission to "distribute the file [...] with modification" but that's not quite the same thing as "permission to make derivative works". Switching back to the software design hat for a moment, do we even care about the database? Shouldn't we only care about parsing the LS_COLORS environment variable? And switching back to the copyright hat, may we reverse engineer the LS_COLORS envvar's syntax and semantics, or would that still count as a derivative work?

At this point, due to legal issues alone I wonder if we shouldn't just use FreeBSD ls's CLICOLOR as our base? Then we'll at last be able to proceed to assessing the feature request from a technical point of view…

(Sorry for the legal detour. I too will be happy when it's over…)

kbd

kbd commented on Mar 14, 2019

@kbd
Author

do we even care about the database? Shouldn't we only care about parsing the LS_COLORS environment variable?

Correct, you only need to care about parsing LS_COLORS, the dircolors --print-database output is just some documentation.

I really appreciate your concern for legality, but LS_COLORS is really a very simple and widely-implemented format. Here's some Python to parse it:

import os

lsc = os.environ['LS_COLORS']
for setting in lsc.split(':'):
    if not setting:
        continue # skip empty
    key, code = setting.split('=')
    print(key, code)

The rest is recognizing if the current file path matches either the pre-defined key (block device=bd, etc.) or file glob and then outputting the associated color codes.

At this point, due to legal issues alone I wonder if we shouldn't just use FreeBSD ls's CLICOLOR as our base?

FWIW that's much more limited and much less widely used. All modern CLI tools (like fd, exa, (GNU) ls) use LS_COLORS. Only Mac (and FreeBSD...) users might even have CLICOLOR set. Btw, here's the Rust implementation of LS_COLORS (MIT licensed) that many Rust CLI tools have been sharing.

phy1729

phy1729 commented on Mar 14, 2019

@phy1729
Member

Parsing LS_COLORS isn't the hard part; local -A var=(${(@s,=,)${(@s,:,)LS_COLORS}}) should do. The difficult part is knowing what each of the keys mean and in which order they apply. As there isn't any official documentation, currently the only way to get it right it is to read the GNU ls source code which is of course GPL licensed.

If someone were to document what the keys mean and their order of precedence by reverse engineering it (i.e. running ls over and over with different LS_COLORS and directory contents), I think that would clear us of any licensing concerns.

danielshahaf

danielshahaf commented on Mar 14, 2019

@danielshahaf
Member
kbd

kbd commented on Mar 14, 2019

@kbd
Author

local -A var=(${(@s,=,)${(@s,:,)LS_COLORS}})

Dang that's some shell-fu right there.

The best documentation that lists all the codes seems to still be that blog post I linked earlier but you made a good point about how precedence applies to them.

Hey @sharkdp, sorry to bother you, but since you implemented projects like vivid and lscolors, could you give any guidance here?

danielshahaf

danielshahaf commented on Mar 15, 2019

@danielshahaf
Member

@sharkdp The question is: can a BSD-licensed project implement an LS_COLORS parser?

sharkdp

sharkdp commented on Mar 15, 2019

@sharkdp

Hey @sharkdp, sorry to bother you, but since you implemented projects like vivid and lscolors, could you give any guidance here?

@sharkdp The question is: can a BSD-licensed project implement an LS_COLORS parser?

I'm not an expert on open source licenses. I can only give my personal interpretation of the matter, but that's not really helpful if what you really need is legal advice.

The way I see it is that LS_COLORS is an open format that is used by many different tools (ls, dircolors, tree, bfs, fd, exa, …). The format was originally invented for ls and I would therefore consider the ls implementation to be the specification (see sharkdp/lscolors#6 (comment) for a similar discussion).

Both my lscolors library/tool as well as bfs by @tavianator (which features a much more solid implementation of the LS_COLORS format) are implementations of that specification (bfs is BSD-licensed, by the way).

We might be able to use the MIT-licensed Rust implementation Keith cited, but even that is questionable. Do we need to check for ourselves that it's not a derivative work of GNU ls? Or can we rely on that repository's maintainers' word?

If somebody can explain to me precisely what "derivative work" means, I might be able to answer that question. My implementation is definitely not based on the ls source code, but I have read the ls source code in order to understand the LS_COLORS format. If that is a problem in and of itself, my interpretation is probably incorrect.

The difficult part is knowing what each of the keys mean and in which order they apply.

Absolutely. There are a lot of subtleties, see for example sharkdp/lscolors#10. I have found some edge cases by automatically comparing my implementation against ls on huge sets of files (see unit tests in lscolors).

sharkdp

sharkdp commented on Mar 15, 2019

@sharkdp

By the way (offtopic?): I think the LS_COLORS format is pretty horrible and severely limited. I would love if there would be a modern, well documented standard to colorize file systems paths.

Limitations of the LS_COLORS format:

  • If colorizing by file name, there is really only one option: to match on a certain suffix. There is no proper way to only highlight files named bar, because we can only add a *bar pattern that will also match hello.bar or foobar.
  • It is not readable. There are dozens of abbreviations that need to be looked up and everything is condensed into a single long line. This is my current LS_COLORS:
pi=0;38;2;0;0;0;48;2;102;217;239:no=0:or=0;38;2;0;0;0;48;2;255;74;68:so=0;38;2;0;0;0;48;2;249;38;114:bd=0;38;2;102;217;239;48;2;51;51;51:*~=0;38;2;122;112;112:cd=0;38;2;249;38;114;48;2;51;51;51:di=0;38;2;102;217;239:mi=0;38;2;0;0;0;48;2;255;74;68:ex=1;38;2;249;38;114:ln=0;38;2;249;38;114:fi=0:*.m=0;38;2;0;255;135:*.h=0;38;2;0;255;135:*.z=4;38;2;249;38;114:*.p=0;38;2;0;255;135:*.c=0;38;2;0;255;135:*.a=1;38;2;249;38;114:*.t=0;38;2;0;255;135:*.d=0;38;2;0;255;135:*.r=0;38;2;0;255;135:*.o=0;38;2;122;112;112:*.ts=0;38;2;0;255;135:*.di=0;38;2;0;255;135:*.cs=0;38;2;0;255;135:*.xz=4;38;2;249;38;114:*.pl=0;38;2;0;255;135:*.cc=0;38;2;0;255;135:*.ko=1;38;2;249;38;114:*.mn=0;38;2;0;255;135:*.pp=0;38;2;0;255;135:*.ui=0;38;2;166;226;46:*.vb=0;38;2;0;255;135:*.gz=4;38;2;249;38;114:*.jl=0;38;2;0;255;135:*.rb=0;38;2;0;255;135:*.md=0;38;2;226;209;57:*.ps=0;38;2;230;219;116:*.hi=0;38;2;122;112;112:*.so=1;38;2;249;38;114:*.js=0;38;2;0;255;135:*.as=0;38;2;0;255;135:*.go=0;38;2;0;255;135:*.bz=4;38;2;249;38;114:*css=0;38;2;0;255;135:*.gv=0;38;2;0;255;135:*.la=0;38;2;122;112;112:*.ml=0;38;2;0;255;135:*.hs=0;38;2;0;255;135:*.cp=0;38;2;0;255;135:*.kt=0;38;2;0;255;135:*.ex=0;38;2;0;255;135:*.rm=0;38;2;253;151;31:*.nb=0;38;2;0;255;135:*.py=0;38;2;0;255;135:*.7z=4;38;2;249;38;114:*.lo=0;38;2;122;112;112:*.hh=0;38;2;0;255;135:*.sh=0;38;2;0;255;135:*.rs=0;38;2;0;255;135:*.fs=0;38;2;0;255;135:*.pm=0;38;2;0;255;135:*.el=0;38;2;0;255;135:*.cr=0;38;2;0;255;135:*.ods=0;38;2;230;219;116:*.php=0;38;2;0;255;135:*.bat=1;38;2;249;38;114:*.tif=0;38;2;253;151;31:*.git=0;38;2;122;112;112:*.inl=0;38;2;0;255;135:*.dll=1;38;2;249;38;114:*.m4v=0;38;2;253;151;31:*.ogg=0;38;2;253;151;31:*.fsi=0;38;2;0;255;135:*.mpg=0;38;2;253;151;31:*.sxi=0;38;2;230;219;116:*.xcf=0;38;2;253;151;31:*.xlr=0;38;2;230;219;116:*.odt=0;38;2;230;219;116:*.pkg=4;38;2;249;38;114:*.yml=0;38;2;166;226;46:*.aif=0;38;2;253;151;31:*.tml=0;38;2;166;226;46:*.htc=0;38;2;0;255;135:*.zip=4;38;2;249;38;114:*.cfg=0;38;2;166;226;46:*.cpp=0;38;2;0;255;135:*.txt=0;38;2;226;209;57:*.aux=0;38;2;122;112;112:*.pro=0;38;2;166;226;46:*.jar=4;38;2;249;38;114:*.pyc=0;38;2;122;112;112:*.sxw=0;38;2;230;219;116:*.epp=0;38;2;0;255;135:*.asa=0;38;2;0;255;135:*.bmp=0;38;2;253;151;31:*.svg=0;38;2;253;151;31:*.pid=0;38;2;122;112;112:*.xml=0;38;2;226;209;57:*.log=0;38;2;122;112;112:*.bin=4;38;2;249;38;114:*.fls=0;38;2;122;112;112:*.fnt=0;38;2;253;151;31:*.ltx=0;38;2;0;255;135:*.exe=1;38;2;249;38;114:*.swp=0;38;2;122;112;112:*.xls=0;38;2;230;219;116:*.h++=0;38;2;0;255;135:*.out=0;38;2;122;112;112:*.mkv=0;38;2;253;151;31:*.erl=0;38;2;0;255;135:*.mp3=0;38;2;253;151;31:*.jpg=0;38;2;253;151;31:*.csv=0;38;2;226;209;57:*.gvy=0;38;2;0;255;135:*.flv=0;38;2;253;151;31:*.vim=0;38;2;0;255;135:*.ilg=0;38;2;122;112;112:*.bak=0;38;2;122;112;112:*.rpm=4;38;2;249;38;114:*.sql=0;38;2;0;255;135:*.ipp=0;38;2;0;255;135:*.sbt=0;38;2;0;255;135:*.tar=4;38;2;249;38;114:*.wmv=0;38;2;253;151;31:*.toc=0;38;2;122;112;112:*.pps=0;38;2;230;219;116:*.tgz=4;38;2;249;38;114:*.kts=0;38;2;0;255;135:*.ttf=0;38;2;253;151;31:*.mid=0;38;2;253;151;31:*.kex=0;38;2;230;219;116:*.tcl=0;38;2;0;255;135:*.ppm=0;38;2;253;151;31:*.ps1=0;38;2;0;255;135:*.pbm=0;38;2;253;151;31:*.otf=0;38;2;253;151;31:*.bbl=0;38;2;122;112;112:*.mli=0;38;2;0;255;135:*.pas=0;38;2;0;255;135:*hgrc=0;38;2;166;226;46:*.bz2=4;38;2;249;38;114:*.tbz=4;38;2;249;38;114:*.xmp=0;38;2;166;226;46:*.vob=0;38;2;253;151;31:*.csx=0;38;2;0;255;135:*.exs=0;38;2;0;255;135:*.pod=0;38;2;0;255;135:*.wav=0;38;2;253;151;31:*.dot=0;38;2;0;255;135:*.nix=0;38;2;166;226;46:*.bst=0;38;2;166;226;46:*.clj=0;38;2;0;255;135:*.ini=0;38;2;166;226;46:*.iso=4;38;2;249;38;114:*.bcf=0;38;2;122;112;112:*.dpr=0;38;2;0;255;135:*.fon=0;38;2;253;151;31:*.mp4=0;38;2;253;151;31:*.hxx=0;38;2;0;255;135:*.bag=4;38;2;249;38;114:*.pdf=0;38;2;230;219;116:*.dox=0;38;2;166;226;46:*.tex=0;38;2;0;255;135:*.htm=0;38;2;226;209;57:*.elm=0;38;2;0;255;135:*.bib=0;38;2;166;226;46:*.doc=0;38;2;230;219;116:*.apk=4;38;2;249;38;114:*.tmp=0;38;2;122;112;112:*.odp=0;38;2;230;219;116:*.gif=0;38;2;253;151;31:*.pgm=0;38;2;253;151;31:*.png=0;38;2;253;151;31:*.deb=4;38;2;249;38;114:*.ico=0;38;2;253;151;31:*.bsh=0;38;2;0;255;135:*.avi=0;38;2;253;151;31:*.mov=0;38;2;253;151;31:*.ind=0;38;2;122;112;112:*.rtf=0;38;2;230;219;116:*TODO=1:*.zsh=0;38;2;0;255;135:*.hpp=0;38;2;0;255;135:*.rst=0;38;2;226;209;57:*.com=1;38;2;249;38;114:*.vcd=4;38;2;249;38;114:*.wma=0;38;2;253;151;31:*.cxx=0;38;2;0;255;135:*.dmg=4;38;2;249;38;114:*.idx=0;38;2;122;112;112:*.cgi=0;38;2;0;255;135:*.awk=0;38;2;0;255;135:*.img=4;38;2;249;38;114:*.ics=0;38;2;230;219;116:*.blg=0;38;2;122;112;112:*.swf=0;38;2;253;151;31:*.lua=0;38;2;0;255;135:*.arj=4;38;2;249;38;114:*.fsx=0;38;2;0;255;135:*.ppt=0;38;2;230;219;116:*.rar=4;38;2;249;38;114:*.c++=0;38;2;0;255;135:*.tsx=0;38;2;0;255;135:*.sty=0;38;2;122;112;112:*.lisp=0;38;2;0;255;135:*.java=0;38;2;0;255;135:*.purs=0;38;2;0;255;135:*.rlib=0;38;2;122;112;112:*.conf=0;38;2;166;226;46:*.psd1=0;38;2;0;255;135:*.mpeg=0;38;2;253;151;31:*.h264=0;38;2;253;151;31:*.html=0;38;2;226;209;57:*.diff=0;38;2;0;255;135:*.less=0;38;2;0;255;135:*.yaml=0;38;2;166;226;46:*.make=0;38;2;166;226;46:*.jpeg=0;38;2;253;151;31:*.json=0;38;2;166;226;46:*.docx=0;38;2;230;219;116:*.orig=0;38;2;122;112;112:*.flac=0;38;2;253;151;31:*.psm1=0;38;2;0;255;135:*.lock=0;38;2;122;112;112:*.tbz2=4;38;2;249;38;114:*.bash=0;38;2;0;255;135:*.dart=0;38;2;0;255;135:*.toml=0;38;2;166;226;46:*.hgrc=0;38;2;166;226;46:*.pptx=0;38;2;230;219;116:*.fish=0;38;2;0;255;135:*.epub=0;38;2;230;219;116:*.xlsx=0;38;2;230;219;116:*.patch=0;38;2;0;255;135:*passwd=0;38;2;166;226;46:*.cmake=0;38;2;166;226;46:*.swift=0;38;2;0;255;135:*.xhtml=0;38;2;226;209;57:*.dyn_o=0;38;2;122;112;112:*.scala=0;38;2;0;255;135:*.mdown=0;38;2;226;209;57:*.ipynb=0;38;2;0;255;135:*.class=0;38;2;122;112;112:*.cabal=0;38;2;0;255;135:*.cache=0;38;2;122;112;112:*.toast=4;38;2;249;38;114:*.shtml=0;38;2;226;209;57:*README=0;38;2;0;0;0;48;2;230;219;116:*shadow=0;38;2;166;226;46:*LICENSE=0;38;2;182;182;182:*.config=0;38;2;166;226;46:*TODO.md=1:*.matlab=0;38;2;0;255;135:*.groovy=0;38;2;0;255;135:*INSTALL=0;38;2;0;0;0;48;2;230;219;116:*.flake8=0;38;2;166;226;46:*.ignore=0;38;2;166;226;46:*.gradle=0;38;2;0;255;135:*.dyn_hi=0;38;2;122;112;112:*COPYING=0;38;2;182;182;182:*Doxyfile=0;38;2;166;226;46:*.gemspec=0;38;2;166;226;46:*.desktop=0;38;2;166;226;46:*Makefile=0;38;2;166;226;46:*setup.py=0;38;2;166;226;46:*TODO.txt=1:*.cmake.in=0;38;2;166;226;46:*COPYRIGHT=0;38;2;182;182;182:*.kdevelop=0;38;2;166;226;46:*README.md=0;38;2;0;0;0;48;2;230;219;116:*configure=0;38;2;166;226;46:*.fdignore=0;38;2;166;226;46:*.markdown=0;38;2;226;209;57:*.rgignore=0;38;2;166;226;46:*.scons_opt=0;38;2;122;112;112:*SConstruct=0;38;2;166;226;46:*SConscript=0;38;2;166;226;46:*INSTALL.md=0;38;2;0;0;0;48;2;230;219;116:*.gitignore=0;38;2;166;226;46:*Dockerfile=0;38;2;166;226;46:*README.txt=0;38;2;0;0;0;48;2;230;219;116:*CODEOWNERS=0;38;2;166;226;46:*.gitconfig=0;38;2;166;226;46:*Makefile.in=0;38;2;122;112;112:*.gitmodules=0;38;2;166;226;46:*Makefile.am=0;38;2;166;226;46:*.travis.yml=0;38;2;230;219;116:*.synctex.gz=0;38;2;122;112;112:*LICENSE-MIT=0;38;2;182;182;182:*MANIFEST.in=0;38;2;166;226;46:*.applescript=0;38;2;0;255;135:*configure.ac=0;38;2;166;226;46:*.fdb_latexmk=0;38;2;122;112;112:*appveyor.yml=0;38;2;230;219;116:*CONTRIBUTORS=0;38;2;0;0;0;48;2;230;219;116:*.clang-format=0;38;2;166;226;46:*CMakeCache.txt=0;38;2;122;112;112:*LICENSE-APACHE=0;38;2;182;182;182:*.gitattributes=0;38;2;166;226;46:*INSTALL.md.txt=0;38;2;0;0;0;48;2;230;219;116:*CMakeLists.txt=0;38;2;166;226;46:*CONTRIBUTORS.md=0;38;2;0;0;0;48;2;230;219;116:*.sconsign.dblite=0;38;2;122;112;112:*CONTRIBUTORS.txt=0;38;2;0;0;0;48;2;230;219;116:*requirements.txt=0;38;2;166;226;46:*package-lock.json=0;38;2;122;112;112
  • There is no way to colorize based on file attributes such as size, modification date, owner, etc.
  • There is no way to extend the format to things like git modification status, for example.
  • LS_COLORS assigns ANSI styles to certain patterns. There is no separation of "content" and "style" (in the HTML / CSS sense). This is why there is a need for additional tools like dircolors or vivid.

I think it could be worth to work on a new standard format. For compatibility reasons, there could be a LS_COLORS generator.

danielshahaf

danielshahaf commented on Mar 16, 2019

@danielshahaf
Member

If somebody can explain to me precisely what "derivative work" means, I might be able to answer that question. My implementation is definitely not based on the ls source code, but I have read the ls source code in order to understand the LS_COLORS format. If that is a problem in and of itself, my interpretation is probably incorrect.

GNU ls is licensed under GPLv3, which requires:

You may convey a work based on the Program, or the modifications to produce it from the Program, in the form of source code under the terms of section 4, provided that you also […] c) license the entire work, as a whole, under this License to anyone who comes into possession of a copy. […]

The phrase "based on" is defined in §0:

To “modify” a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a “modified version” of the earlier work or a work “based on” the earlier work.

The part about "requiring permission" is because, under copyright law, the copyright owner's permission is normally required to distribute a copyrighted work or works derived from it (that's why J. K. Rowling receives royalties from sales of Harry Potter translations, even though the translations are separately copyrighted).

In English, all that adds up to: if an LS_COLORS parser in zsh-syntax-highlighting would be considered a derivative work of GNU ls of a sort that requires the original copyright owner's permission to distribute, then the aforequoted GPLv3 §5 would apply, and zsh-syntax-highlighting would be required to be licensed under GPL, rather than BSD.

danielshahaf

danielshahaf commented on Mar 16, 2019

@danielshahaf
Member

Forgot to say: thanks for joining this thread, @sharkdp!

tavianator

tavianator commented on Mar 16, 2019

@tavianator

@sharkdp If you want to collaborate on some better replacement for LS_COLORS, I'd support it in bfs.

Also in my confident but non-lawyer opinion, just implementing an LS_COLORS parser does not make your code a derivative work of GNU ls.

danielshahaf

danielshahaf commented on Mar 17, 2019

@danielshahaf
Member

To be clear, I agree that zsh-syntax-highlighting would not be a derivative work of GNU ls even if we shipped an LS_COLORS parser. My concern is that the parser would be (able to be argued to be) a derivative work and under GPLv3 §5 the "entire work" (= all of z-sy-h) would be required to be GPL'd.

I'm not sure how to proceed. Perhaps we should give the GNU ls copyright holders a bell and ask their opinion/permission?

phy1729

phy1729 commented on Mar 23, 2019

@phy1729
Member

It seems zsh itself has an LS_COLORS parser/user, so perhaps we can use that code as a base?

https://github.com/zsh-users/zsh/blob/master/Src/Zle/complist.c#L151

trapd00r

trapd00r commented on Apr 30, 2019

@trapd00r

Hey guys,

I'm not much for licensing, but as the author of zsh-syntax-highlighting-filetypes (and LS_COLORS and File::LsColor) I hereby grant you permission to do what you want with it. Is that a license enough? :)

If colorizing by file name, there is really only one option: to match on
a certain suffix. There is no proper way to only highlight files
named bar, because we can only add a *bar pattern that will also
match hello.bar or foobar.

False. :)
LS_COLORS="${LS_COLORS}:*bar=38;5;220:*foobar=38;5;197:*.bar=38;5;196"

lscolors

tavianator

tavianator commented on Apr 30, 2019

@tavianator

@trapd00r You'll notice that ls will color a file notbar the same as bar with that LS_COLORS. That's the annoying part.

trapd00r

trapd00r commented on Apr 30, 2019

@trapd00r

Right. My point was that the asterisk can go anywhere or nowhere at all (to match an exact filename).

tavianator

tavianator commented on Apr 30, 2019

@tavianator

@trapd00r It has to come at the beginning:

$ LS_COLORS="${LS_COLORS}:bar=01;33:" ls
ls: unparsable value for LS_COLORS environment variable
...
$ LS_COLORS="${LS_COLORS}:bar*=01;33:" ls
ls: unparsable value for LS_COLORS environment variable
...
danielshahaf

danielshahaf commented on May 4, 2019

@danielshahaf
Member

I'm not much for licensing, but as the author of zsh-syntax-highlighting-filetypes (and LS_COLORS and File::LsColor ) I hereby grant you permission to do what you want with it. Is that a license enough? :)

I'm afraid I'm too short on time to look into legal questions presently, but I do wish to say, Thanks very much for this contribution, @trapd00r.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @trapd00r@phy1729@kbd@tavianator@danielshahaf

        Issue actions

          Highlight paths with colors from LS_COLORS? · Issue #605 · zsh-users/zsh-syntax-highlighting