ls: Windows - Friendlier Windows listing

[AndreasBrostrom]

When ls -l is used on a windows system you receive:

---------- 1 somebody somegroup      0 May 19 10:04 ls.exe -> 'C:\Users\andre\Programs\Bin\coreutils.exe'

In powershell using Get-ChildItem (powershell ls) on a linux system this is translated well showing permissions, user and group:

lrwxrwxrwx andre    andre    5/18/2022 10:24    26 coreutils ->  ../lib/coreutils/coreutils

To make ls more NTFS friendly; ls could mirror the powershells output for handling the list output and utilize the object type indicator instead and ignore USER and GROUP

Below you can see a output using Get-ChildItem on a windows:

la---          2022-05-18    16:06              0 coreutils.exe -> C:\Programs\Lib\coreutils\coreutils.exe

l (link) d (directory) a (archive) r (read-only) h (hidden) s (system) https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.management/get-childitem?view=powershell-7.2

As a example this could then be the output for a Windows file system:

PS > ls.exe -l
total 2707968
la---    1          0 May 18 16:06 coreutils.exe -> 'C:\Programs\Lib\coreutils\coreutils.exe' 
la---    1          0 May 19 10:04 ls.exe -> 'C:\Users\andre\Programs\Bin\coreutils.exe'
-a---    1      89088 Dec  2 11:57 steam.exe

Screenshots of terminals

Windows - Powershell

Linux - Bash Powershell

[tertsdiepraam]

Thanks! This is very much a design decision, with a couple of different things to consider:

1. What do Windows users expect?
2. What do Unix users working on Windows expect? (Because we aim to be a rewrite of the GNU coreutils, it makes sense to expect the same behaviour on Windows as on Unix)
3. What do script writers expect?

Arguably, the last point is less important for ls, because it should not be used in scripts, but I think it is still used a lot of scripts and we don't want to break those. So let's try to answer these questions.

1. This is what you suggest. ls on Windows should behave like ls in cmd or Powershell. It should show the information that is relevant to the OS you're on.
2. This is tougher to answer. I think it's probably what we have now. It's the same command as on Unix with some (admittedly ugly) filler for missing information. One might also expect some slight translation from unix concepts to windows concepts where possible.
3. Script writers mostly want the output to be consistent on all platforms, so any parsing (which, again, is discouraged) would not fail on Windows, while it succeeds on unix platforms. Also if scripts are currently running on Windows, it might be through Git Bash, which I think does the same thing that we currently do.

With those conflicting expectations, I don't think there's a lot we can do. Maybe there are some small improvements we can make while preserving the general format. Some possibilities (not sure if they are correct):

• Use the read-only flag to fill in the permissions somewhat. I.e. if read-only is active we do r--r--r-- and otherwise rwxrwxrwx.
• Figure out the owner of the file and use that in the user column (somewhat like this stackoverflow answer)

[AndreasBrostrom]

Using WSL this is the output when navigating to the windows file system i would return the owner and group belonging to the current main user of the WSL system su will not change owner or group to root or anything else. WLS ls -la using default coreutils example below:

Picture

Windows groups and user system work complacently different from how Linux does and is not directly applicable.

Groups and user example below:

PS > whoami
b-station\andre
Administrator in B-Station in C:\bin
PS > whoami /groups

GROUP INFORMATION
-----------------

Group Name                                                    Type             SID                                                                                                         Attributes
============================================================= ================ =========================================================================================================== ===============================================================
Everyone                                                      Well-known group S-1-1-0                                                                                                     Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\Local account and member of Administrators group Well-known group S-1-5-114                                                                                                   Mandatory group, Enabled by default, Enabled group
BUILTIN\Administrators                                        Alias            S-1-5-32-544                                                                                                Mandatory group, Enabled by default, Enabled group, Group owner
BUILTIN\Users                                                 Alias            S-1-5-32-545                                                                                                Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\NETWORK                                          Well-known group S-1-5-2                                                                                                     Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\Authenticated Users                              Well-known group S-1-5-11                                                                                                    Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\This Organization                                Well-known group S-1-5-15                                                                                                    Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\Local account                                    Well-known group S-1-5-113                                                                                                   Mandatory group, Enabled by default, Enabled group
MicrosoftAccount\[email protected]                     User             S-1-11-96-3623454863-58364-734123-14623123-1597581903-9464323-63323446572-1234663523-18084664304-5764345346 Enabled group
NT AUTHORITY\NTLM Authentication                              Well-known group S-1-5-64-10                                                                                                 Mandatory group, Enabled by default, Enabled group
Mandatory Label\High Mandatory Level                          Label            S-1-16-12288

Answering from my point:

• What do Windows users expect?, What do Unix users working on Windows expect? (Because we aim to be a rewrite of the GNU coreutils, it makes sense to expect the same behaviour on Windows as on Unix), What do script writers expect? To be able to utilize ls in a powershell environment witch is does today with no problems see below.

  PS > ls.exe | Foreach-Object { echo "$_" }
  coreutils.exe
  ln.exe
  ls.exe
  

  for the list param you could eather sow the object owner and group this would probably majority of time return BUILTIN\Administrators or Computer\Name don't se the direct usefullness tho.

  PS > Get-Acl .\coreutils.exe
  
      Directory: C:\Programs\Bin
  
  Path          Owner                  Access
  ----          -----                  ------
  coreutils.exe BUILTIN\Administrators BUILTIN\Administrators Allow  FullControl…
  

  PS > Get-Acl .\.bin\adb-push.cmd
  
      Directory: C:\Users\andre\.bin
  
  Path         Owner           Access
  ----         -----           ------
  adb-push.cmd B-Station\andre NT AUTHORITY\SYSTEM Allow  FullControl…
  
  

  What i expect from the ls command should be similar but same cross each platform which relevant adjustments ether showing proper windows user or not showing it at all due to the OS relevance. I would never expect a shell script to function on a windows system outside of WSL. Powershell tho do function cross platform but ls usage as of shown above do function as expected especially using non list format.

Some experiments

When piping list in powershell when piping to Select -First 1 it will show size.

PS > ls.exe -l | Select -First 1
total 14697

ls.exe -l | Format-Table -AutoSize does nothing in particular cause it will not be able to make a table out of if. Same goes for filter actions when tempting to do anything with the "table": ls.exe -l | Format-Table -AutoSize | ForEach-Object { echo $_.Name } ls.exe -l | Format-Table -AutoSize | ForEach-Object { echo $_.total }

[tertsdiepraam]

I like WSL as an example! I think that should be our role model so to speak. They seem to have made some sensible choices there. Don't hesitate to open PRs to fix this issue. I don't work on Windows myself so I can't really work on this directly.

[AndreasBrostrom]

Not competent enough with rust for dong this my self i am afraid.

[jkrejcha]

For reference, GetSecurityInfo will return the SID of the user and group*.

Another question is how to handle SIDs that can't be mapped to a username. This is a common occurrence on Windows (especially when used with capability SIDs (see also) or when a name can't be resolved over the network for whatever reason.

Perhaps we might want a cached_sid2name function for Windows (similar to cached_uid2usr and cached_gid2grp) and if a lookup fails, just fallback to the SID itself (this is the Windows permissions dialogs do)?

It is theoretically possible to go through the ACL and see if read, write, and execute permissions are allowed on the SIDs for the user and group.

Other really doesn't have an equivalent in Windows (Everyone is inaccurate, as POSIX other doesn't include the user or group). Regardless, rwxrwxrwx isn't the best (and nor is r-xr-xr-x).

Relevant Windows API functions and articles:

• GetSecurityInfo
• LookupAccountSid
• How AccessCheck Works

* It's worth noting, although perhaps irrelevant, that technically these aren't users and groups per se (but they are identifiable by their SID and potentially have a name). In fact, on a lot of files, the SID returned isn't (SYSTEM isn't a user or group for example. In some cases, service SIDs can own stuff too (most notable with TrustedInstaller)).