Codefactor issues are existing ones

@SteveL-MSFT I am very concerned that we are colorizing many things by default. This is a very sensitive area for many people. I think we need themes support and the default theme needs to be approved by MSFT accessibility team.

@iSazonov from an accessibility standpoint, the rule that applies here is sufficient contrast between colors (foreground and background) which is covered by the default selections. Can certainly add a [bool] $PSStyle.FileInfo.Color member to make it easy to turn on/off if you feel that is necessary. Themes should really be the domain of the terminal and not the shell.

Let's continue the discussion in the issue #9270

My eyes can hold up quite well all day with the classic Windows soothing color style, but they will definitely be against the checkered color scheme.

Themes should really be the domain of the terminal and not the shell.

As I mentioned early, $PSStyle should be evaluated based on TermInfo, and we need to map $PSStyle to TermInfo - the mapping I named theme and the themes should be switchable and customizable.

This was already done in the terminal-icons module, ipso facto it should be rejected? ¯\_(ツ)_/¯

@Jaykul, this PR makes changes to FileSystemProvider to make it as fast as possible. Certainly it's feasible to call a native POSIX API to determine if a file on Linux/macOS is an executable or call a win32 API to check if an object is a reparse point and obtain the target within a format ps1xml, but it would be much more code.

@Jaykul, this PR makes changes to FileSystemProvider to make it as fast as possible. Certainly it's feasible to call a native POSIX API to determine if a file on Linux/macOS is an executable or call a win32 API to check if an object is a reparse point and obtain the target within a format ps1xml, but it would be much more code.

I missed that Platform.NonWindowsIsExecutable is a private method (sigh), but I don't think that matters.

Ignoring who wrote this code, the PowerShell team pledged that feature requests would be aggressively rejected if they can be done externally, and this has, in fact, already been done multiple times in modules. Just for example:

• PSColor was written in 2014 and has over 8k downloads on the gallery (which it predates).
• Terminal-Icons was released 18 months ago and has over 3k downloads.

Many of these modules do far more than just color files, and have spawned their own copy cats and even modules which depend on them.

The two I picked do things in a Windows-specific way (i.e. coloring files by extension) --they're the ones I've personally used in the past-- but a module can easily duplicate a PInvoke or two and implement this in more cross-platform way, and still ship externally so as to not end up doing the work twice (and breaking the other modules if the experimental flag is ever removed).

Building this into PowerShell also adds a lot of maintenance, because it will mean that this repo and team are going to get requests for every other type of coloring of Get-ChildItem output which you may have forgotten, including requests to add icons, to support the LS_COLOR environment variable, etc. 😣

In my opinion this should not be merged. I do think the functionality to check IsExecutable should be added to the FileInfo object as a CodeProperty (there's a lot of prescedent for that).

This pull request has been automatically marked as Review Needed because it has been there has not been any activity for 7 days.
Maintainer, please provide feedback and/or mark it as Waiting on Author

@Jaykul I would agree that anything more than what is provided here would make sense to provide as a module. The intent here is only parity with ls --color.

Created discussion for partial format updates to support other PSColor and Terminal-Icon scenarios #15746

@PowerShell/powershell-committee discussed this at length today, and many of us agreed that you made some excellent points in this thread, @Jaykul. In particular, we empathize with your point about our stance to push innovation happening out of the PS repo vs. within the repo, and that's certainly the general case.

However, the original experimental feature--PsAnsiRendering, which includes the $PSStyle variable--is a feature that we felt is standard enough in all modern shells that this is a gap we need to fill in the mainline product. (As an additional data point, the lack of a new dependency here helps push this over the edge, as none of this work is significantly contributing to the size of the package.)

Now, to your point, there's very cool stuff happening in other modules like PSColor and Terminal-Icons. We definitely don't want to invalidate that work with anything we do, but a cursory analysis shows that modules like that should still work to override this work just fine. And in fact, we want to create a more extensible substrate for modules like that to easily implement colorization for a larger set of types. This assumption could be wrong, but that's exactly the sort of thing we'd like to learn by shipping this as an experimental feature.

Another reason for shipping this work is to validate that the $PSStyle work is the correct approach. We renamed the experimental feature so that it's a part of the same namespace as the rest of the PSAnsiRendering work. Based on the real world usage and issues, we're open to not necessarily shipping both of these as stable at the same time.

To all those ends, we're going to merge this as experimental, but we'll still evaluate it as any other experimental feature before we promote it to stable. I believe that @SteveL-MSFT also plans to write an RFC for all the $PSStyle work (based on #13071) before this happens.

As a personal side note, I'd like to do some further analysis of the default colors before shipping as stable as well. @SteveL-MSFT took these straight from ls, but it might be a better idea to fit with the default colorization of PSReadline.

However, the original experimental feature--PsAnsiRendering, which includes the $PSStyle variable--is a feature that we felt is standard enough in all modern shells that this is a gap we need to fill in the mainline product.

Standard? This standard is so old that you won't surprise anyone. PowerShell was approved and came into being only because it was a next generation shell with great innovations.
Why copy bash (you mean it, don't you?) if you already have it? Run bash and be happy!

Don't you have any breakthrough ideas at all? What about Jason's PSMore for next dynamic formatting? Jim's DSL? New modern remoting? There are others lost in the midst of several thousand issues. Some interesting ideas seem to have been started but forgotten.

PowerShell Core is celebrating its fifth anniversary and we have to ask where are the unparalleled innovations?
(I'm not writing this to diminish achievements, but to inspire new ones.)

(As an additional data point, the lack of a new dependency here helps push this over the edge, as none of this work is significantly contributing to the size of the package.)

You could open Notepad and try colorize - on the second entity you will feel sorry for your time and the bloated XML will horrify you :-)

Another reason for shipping this work is to validate that the $PSStyle work is the correct approach.

It makes no sense to spend time on coping old school semi-features (especially if there are already alternative modules).
Do real innovations!

Yay, many thanks for this @SteveL-MSFT !

🎉v7.2.0-preview.8 has been released which incorporates this pull request.🎉

Handy links:

• Release Notes