This issue is meant to capture the broader Windows visibility problem that sits behind a few narrower requests.
On Unix-like systems, hidden files are mostly a naming convention: entries beginning with (.). On Windows, there are at least three separate concepts that can all end up lumped together in eza -a output:
- dot-prefixed entries such as
.dotnet or .nuget
- entries hidden via the Windows
hidden file attribute
- hidden links / aliases / junction-style entries in the user profile, such as
Application Data, Local Settings, SendTo, etc.
Today, -a is often too broad on Windows because it enables all of these at once.
For example, a Windows user may want:
- dotfiles like
.dotnet and .nuget
- but not noisy hidden-attribute files such as
NTUSER.DAT, XORXOR*.doc, or ZZZZZ*.pdf
- and possibly also hidden profile links such as
Local Settings or SendTo
That means this is probably not a single-feature problem.
It looks more like eza needs independent visibility controls for at least:
-
name-hidden entries
- dot-prefixed entries on all platforms
- Windows
_name entries if eza continues to treat them as hidden-by-name
-
Windows hidden-attribute entries
- regular files and directories hidden by filesystem attribute
-
Windows hidden links / aliases / junctions
- entries that are hidden, but also useful to surface independently from hidden regular files
A narrower first step is already being addressed by adding --show-dotfiles, which helps with the common "show dotfiles, but not all Windows hidden files" case.
This issue is for the remaining Windows-specific follow-up: describing the problem space clearly enough that future flags/options can be designed as separate capabilities rather than forcing everything through -a.
Related issues:
This issue is meant to capture the broader Windows visibility problem that sits behind a few narrower requests.
On Unix-like systems, hidden files are mostly a naming convention: entries beginning with (
.). On Windows, there are at least three separate concepts that can all end up lumped together ineza -aoutput:.dotnetor.nugethiddenfile attributeApplication Data,Local Settings,SendTo, etc.Today,
-ais often too broad on Windows because it enables all of these at once.For example, a Windows user may want:
.dotnetand.nugetNTUSER.DAT,XORXOR*.doc, orZZZZZ*.pdfLocal SettingsorSendToThat means this is probably not a single-feature problem.
It looks more like eza needs independent visibility controls for at least:
name-hidden entries
_nameentries if eza continues to treat them as hidden-by-nameWindows hidden-attribute entries
Windows hidden links / aliases / junctions
A narrower first step is already being addressed by adding
--show-dotfiles, which helps with the common "show dotfiles, but not all Windows hidden files" case.This issue is for the remaining Windows-specific follow-up: describing the problem space clearly enough that future flags/options can be designed as separate capabilities rather than forcing everything through
-a.Related issues: