exa: exa is not available on Windows

anyway, cargo install --git https://github.com/zkat/exa should work as a workaround for those who just want a quick install without all the features yet.

Hi guys. I’ve created #820 for Windows support. Check that out if you’re interested 😄

For anyone interested, here’s how I’m setup on Windows to call exa in WSL from PowerShell more easily.

In your PowerShell profile (ie: %UserProfile%\Documents\Microsoft.PowerShell_profile.ps1):

function Invoke-Exa {
    & bash.exe -c "exa $args"
}

Set-Alias exa Invoke-Exa

Also, if you’re on a recent build of Windows 10 (at least build 17093), I highly recommend configuring your /etc/wsl.conf mount options to support the new metadata flag. This allows file metadata such as permissions to persist on files accessed in Windows from WSL.

Call from PowerShell in ConEmu:

Call from vanilla PowerShell (obviously not as pretty):

So far so good 😃

Only one test failing, and then it’s time to start porting and enabling whatever bits of -l can actually be enabled on Windows…

I’m toying around with this. Current problems I’ve ran into and workarounds:

• exa’s fs::file is very Unix specific. Things like is_block_device/is_char_device don’t really have a Windows equivalent. However, this is actually relatively easy to work around; a dummy trait can be implemented that just returns false for all of these. For eventual Windows-specific properties, the same approach can be taken to stub them out on Unix. It would be cleaner to split these things up into Windows and Unix file types, including separate styling extensions, but might be overkill to do that refactor.

• the users crate can just be skipped entirely, and we can ignore users/groups on windows (for now) by providing some dummy impls in a few places, and just skipping User/Group support in a few other places

• Windows has a much more complicated permissions model. However, the basic permissions can be distilled into Unix bits, at least as far as “does user have permission” or “does user not have permission”. I can’t implement this on the dummy traits though, so it would need to be implemented directly on file.

• options::parser uses OsString and does direct manipulations, assuming that the string is composed of bytes. That’s not the case on Windows. Would be better to convert from OsString to regular strings, and then iterate over string arguments – or to use something like clap-rs for options parsing. (Just read the comments on the top – I understand why it has its own parser now. I’ll think about how to do this on windows.) – Took a stab at this. It’s going to be complicated, because it assumes that the args are &OsStr, and that this can be coverted to/from &[u8] at will. That’s not true on Windows, though I really don’t understand why. There is a encode_wide() that returns a u16 iterator, and I can create a brand new Vec<u16> from that. But I can’t get the underlying u16 slice, and can’t go back and forth between that and &OsStr.

I’m currently trying to figure out a quick workaround for the OsString bits in order to move further.

I think a version that handles the basics – filenames, sizes, times, executable/not, directory/symlink/etc. and just stubs everything else out should be possible pretty quickly. Then the rest can be implemented piecemeal.

For anyone interested, here’s how I’m setup on Windows to call exa in WSL from PowerShell more easily.

In your PowerShell profile (ie: %UserProfile%\Documents\Microsoft.PowerShell_profile.ps1):

function Invoke-Exa {
    & bash.exe -c "exa $args"
}

Set-Alias exa Invoke-Exa

Also, if you’re on a recent build of Windows 10 (at least build 17093), I highly recommend configuring your /etc/wsl.conf mount options to support the new metadata flag. This allows file metadata such as permissions to persist on files accessed in Windows from WSL.

Call from PowerShell in ConEmu:

Call from vanilla PowerShell (obviously not as pretty):

Thanks for this; I didn’t know I could call bash from windows like this. I found this to be a bit more stable/convenient:

Function Invoke-Exa {
	Param (
		[string]$Path = "./",
		[switch]$Recurse
	)
	if ($Recurse) {
		$r = "--recurse"
	}
	$fullPath = (Get-Item $Path).FullName
	$linuxPath = "/mnt/" + $fullPath[0].ToString().ToLower() + ($fullPath.Substring(2) -replace "\\","/")
	& bash.exe -c "/usr/local/bin/exa --icons --group-directories-first -l $r $linuxPath"
}

I’d like to mention as of now the Linux 64-bit binary works perfect under Windows Subsystem for Linux, can be posted on the website before the actual Windows support is ready.

As for the ansi color code issues, a build which still outputs them is very useful on windows if you use conemu for your console emulator as it parses the codes and outputs color as you might expect. That means you can ignore that particular problem and solve it at a later date if need be.

As you can tell by the label – I do want to have Windows support, but until I can work out how to do it, it’ll have to be in the eventually column 😦

There are currently three problems preventing Windows support:

• The users crate uses the uid_t and gid_t types from libc, which are guaranteed to exist in Unix environments, but will not exist under Windows, which does users and groups differently. This is the error you’re getting. I’m not sure how to adapt the users crate for Windows, but there would have to be equivalent functions of “find user information from ID” and “find list of users in a group” functions.
• The locale crate looks for Unix-style month and day names in the Unix path. This would also have to use the Windows API.
• The formatting codes in ansi-term are designed for ANSI-style terminals, rather than Windows terminals. (This won’t stop it from compiling, but the output would make it unusable)

I’m not familiar enough with Windows to know if the API offers the functionality. I mean, it probably does, but I’m not sure how to find it.

Closing this, exa is unmaintained (see https://github.com/ogham/exa/issues/1243), and the the active fork eza has better support for Windows than exa.

I’m giving this a shot. I’ve gotten through most of the compiler errors and I just need to putz around with the parser (as https://github.com/ogham/exa/issues/32#issuecomment-538831310 mentioned, it needs to be updated for windows OsStrings). Assuming I can work around that bit, I should have a PR ready soonish. No promises, though!

Also, for those of you who typically use non-windows operating systems but would like access to one temporarily for testing your software, there are several options. One, you can use the free VMs that Microsoft makes available: https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/ Two, everyone can get some limited number of hours per month on Azure, and they have Windows VMs that you can use, some with Visual Studio already installed. Three, once the Windows code is done, you can use the free-tier of AppVeyor to do the continuous builds.

bro you definitely wanna check out lsd which stands for ls-deluxe, and it can be installed natively on Windows 11 using scoop. It’s a good alternative if you don’t want to use the default Get-Childitem cmdlet or don’t want to run exa through WSL2 (which introduced some extra latency on my machine). It’s also written in rust if that’s what you care about.

@vvuk , I’ve thought about working to improve the Windows story here as well, but my stack is otherwise full at the moment. But, I did some initial research, and I came across lsd which is a similar program, also written in rust. lsd has a working Windows implementation with a display of ownership and permissions. It might be worth a look for some inspiration.