exa is not available on Windows

[sirxyzzy]

You mentioned you don't have a Windows machine, I do, I tried to compile exa (without git, for now) and it looks as if a couple of types are not in std. or maybe they are, but the error message is hard to understand...

C:\Users\andy.cargo\registry\src\github.com-1ecc6299db9ec823\users-0.2.3\src\lib.rs:117:27: 117:32 error: unresolved import libc::uid_t. There is no uid_t in libc C:\Users\andy.cargo\registry\src\github.com-1ecc6299db9ec823\users-0.2.3\src\lib.rs:117 use libc::{c_char, c_int, uid_t, gid_t, time_t}; ^~~~~ C:\Users\andy.cargo\registry\src\github.com-1ecc6299db9ec823\users-0.2.3\src\lib.rs:117:34: 117:39 error: unresolved import libc::gid_t. There is no gid_t in libc C:\Users\andy.cargo\registry\src\github.com-1ecc6299db9ec823\users-0.2.3\src\lib.rs:117 use libc::{c_char, c_int, uid_t, gid_t, time_t};

---

Moderator edit: Windows support is being worked on in https://github.com/ogham/exa/pull/820

[ogham]

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.

[sirxyzzy]

Thanks for the pointers, this is most helpful

OK,all those problems seem likely to have solutions, I even found an Ansi emulator (ansicon) C library that could be of use, but frankly this may be better solved by creating a slightly higher level abstraction for screen operations (move here, color there) type API which could be ANSI implemented on Unix platforms, and custom implemented for Windows.

I may noodle on this a bit, I like Rust a lot, but the Windows support in general seems a bit patchy. I feel that while that is the case any chance Rust has for widespread adoption is limited. I hope to improve that situation. If I get anything useful on the windows side, are you interested, or are you one of those who prefers not to support Windows at all? I could understand that given the oddly acrimonious history of the two tribes.

I plan on getting the git integration sorted too, as I want to build some new and novel tools around that, using Rust, I’m willing to bet that will have some challenges too.

Again, thanks.

Andy P++

From: Ben S Sent: ‎Tuesday‎, ‎February‎ ‎24‎, ‎2015 ‎8‎:‎33‎ ‎AM To: ogham/exa Cc: Andy Philpotts

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.

— Reply to this email directly or view it on GitHub.

[ogham]

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 :(

[evhub]

Just ran across exa and was disappointed to discover there was no Windows support! I don't know enough Rust to help out with the port, but if you don't have a Windows machine and you're looking for a way to test on Windows, you could try AppVeyor (which is free for open-source) with a configuration like the one here.

If it's at all helpful, I tried installing on my machine anyway and got:

> cargo install --git https://github.com/ogham/exa
    Updating git repository `https://github.com/ogham/exa`
   Compiling libc v0.2.24
   Compiling num-traits v0.1.39
   Compiling glob v0.2.11
   Compiling byteorder v0.4.2
   Compiling percent-encoding v1.0.0
   Compiling getopts v0.2.14
   Compiling matches v0.1.6
   Compiling rustc-serialize v0.3.24
error: the `?` operator is not stable (see issue #31436)
   --> C:\Users\Evan\.cargo\registry\src\github.com-1ecc6299db9ec823\percent-encoding-1.0.0\lib.rs:284:13
    |
284 |             formatter.write_str(c)?   Compiling unicode-bidi v0.3.3

    |             ^^^^^^^^^^^^^^^^^^^^^^^

error: attributes on non-item statements and expressions are experimental. (see issue #15701)
  --> C:\Users\Evan\.cargo\registry\src\github.com-1ecc6299db9ec823\unicode-bidi-0.3.3\src\prepare.rs:99:17
   |
99 |                 #[cfg(test)]
   |                 ^^^^^^^^^^^^

error: aborting due to previous errorerror[E0412]   Compiling locale v0.2.2
: type name `Range` is undefined or not in scope
  --> C:\Users\Evan\.cargo\registry\src\github.com-1ecc6299db9ec823\unicode-bidi-0.3.3\src\deprecated.rs:25:26
   |
25 | pub fn visual_runs(line: Range<usize>, levels: &[Level]) -> Vec<LevelRun> {
   |                          ^^^^^^^^^^^^ undefined or not in scope
   |
   = help: you can import several candidates into scope (`use ...;`):
   = help:   `std::collections::btree_map::Range`
   = help:   `std::collections::btree_set::Range`
   = help:   `std::ops::Range`

error[E0425]: unresolved name `min`
  --> C:\Users\Evan\.cargo\registry\src\github.com-1ecc6299db9ec823\unicode-bidi-0.3.3\src\deprecated.rs:45:25
   |
45 |             min_level = min(level, min_level);
   |                         ^^^

error[E0425]: unresolved name `max`
  --> C:\Users\Evan\.cargo\registry\src\github.com-1ecc6299db9ec823\unicode-bidi-0.3.3\src\deprecated.rs:46:25
   |
46 |             max_level = max(level, max_level);
   |

                        ^^^

Build failed, waiting for other jobs to finish...
error: aborting due to 4 previous errors

Build failed, waiting for other jobs to finish...
error: failed to compile `exa v0.7.0 (https://github.com/ogham/exa#f54bc417)`, intermediate artifacts can be found at `C:\Users\Evan\AppData\Local\Temp\cargo-install.XaPfveabwX8d`

Caused by:
  Could not compile `percent-encoding`.

To learn more, run the command again with --verbose.

I also tried installing libgit2 and got:

> cargo install --git https://github.com/alexcrichton/git2-rs
    Updating git repository `https://github.com/alexcrichton/git2-rs`
    Updating registry `https://github.com/rust-lang/crates.io-index`
   Compiling log v0.3.8
   Compiling winapi v0.2.8
   Compiling winapi-build v0.1.1
   Compiling unicode-xid v0.0.3
   Compiling bitflags v0.3.3
   Compiling libc v0.2.29
   Compiling vcpkg v0.2.2
   Compiling rustc-serialize v0.3.24
   Compiling pkg-config v0.3.9
   Compiling gcc v0.3.51
   Compiling kernel32-sys v0.2.2
   Compiling cmake v0.1.24
   Compiling libz-sys v1.0.16
error: attributes on non-item statements and expressions are experimental. (see issue #15701)
   --> C:\Users\Evan\.cargo\registry\src\github.com-1ecc6299db9ec823\cmake-0.1.24\src\lib.rs:423:21
    |
423 |                     #[cfg(windows)] {
    |                     ^^^^^^^^^^^^^^^

error: aborting due to previous error

Build failed, waiting for other jobs to finish...
error: failed to compile `systest v0.1.0 (https://github.com/alexcrichton/git2-rs#60a49f46)`, intermediate artifacts can be found at `C:\Users\Evan\AppData\Local\Temp\cargo-install.nsopyCWaNwbL`

Caused by:
  Could not compile `cmake`.

To learn more, run the command again with --verbose.

[kasajian]

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.

[martinlindhe]

@evhub I believe the errors you are getting about experimental features is because your rust compiler is out of date, try rustup update.

Current stable version is 1.19, see which version you are using with rustc -V

[Kethku]

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.

[Kethku]

Also seems like finding the terminal size is a problem as it uses the unix ioctl command which I dont think works in windows...

Maybe that code can be replaced with https://github.com/eminence/terminal-size?

[PJB3005]

My attempts at building on Windows with latest stable Rust so far have resulted in a ton of errors from the rust-users crate. Gonna see if I can get this to work though.

[PJB3005]

Ok so right now, there's a couple dependencies that fail to compile outright on Windows:

• users
• datetime
• zoneinfo-compiled

Then there's also the fact that basically all permissions handling is also Unix-specific, which is another blocker. The last two of those failing crates are both date time handling and might be able to be replaced with chrono, users might be more tricky to replace however.

[mqudsi]

Note that on Windows 10, the WSL team has worked to make conhost mostly xterm-256color-compatible, so that should take care of one of the issues.

[Kethku]

Now if they could make powershell or cmd similarly compatible...

[mqudsi]

@kethku I don't think you understand the split between shell and terminal under Windows. PowerShell and CMD both run under conhost.

[PJB3005]

It might be possible to use the same approach as colorama, where on Windows it hooks stdout, strips control characters and instead fires off the relevant win32 API calls. Not sure how much Rust allows hooking stdout, but if it does this should make it possible to get colors working in conhost without touching the rest of the code much.

[Kethku]

Yes, but they don't act like a Unix terminal. MS added support for Unix terminal codes for color etc but they didn't add a way for powershell or cmd to emit those codes. This comes up if you want to use powershell inside of emacs for example.

On Aug 9, 2017 4:51 AM, "Mahmoud Al-Qudsi" [email protected] wrote:

@Kethku https://github.com/kethku I don't think you understand the split between shell and terminal under Windows. PowerShell and CMD both run under conhost.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ogham/exa/issues/32#issuecomment-321233192, or mute the thread https://github.com/notifications/unsubscribe-auth/ADK2722BGmQcaZsg8B8uemHFgtDasQEBks5sWZ1SgaJpZM4DknBI .

[Kethku]

Sweet. https://github.com/ogham/exa/pull/237 fixes the terminal size problem.

[QrchackOfficial]

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.

[ntpeters]

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):

[pbnoyz]

Is it possible to use GetNamedSecurityInfo winapi to retrieve user infos and permissions?

[sergeevabc]

Windows binary is still anticipated.

[RoniJacobson]

• 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)

This has a simple solution. It is unclear why this works, but it does: if you send an empty call out into the cmd, then ansi codes start working. The following code will print hello in red in your terminal.

use std::process::Command;
fn main() {

let mut list_dir = Command::new("cmd");
list_dir.arg("/c");
// Execute `ls` in the current directory of the program.
list_dir.status().expect("process failed to execute");

println!("\x1b[31mhello\x1b[0m");
}

Also, in the new upcoming windows terminal the escape codes are enabled by default.

[vvuk]

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.

[rivy]

@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.

[sergeevabc]

@rivy, I have not found any Windows-ready binaries of lsd (checked Releases and Issue Tracker).

[rivy]

lsd does build successfully under Windows. But you're correct, there are no current Windows builds included in the release assets. There is an open issue (see GH:Peltoche/lsd#188 requesting the addition of Windows builds, but it's obviously not resolved.

[rivy]

@sergeevabc , I created a quick GitHub workflow that compiles and saves the results as artifacts (see rivy/rust.lsd:GHA). Both i686 and x86_64 versions are available from the "Artifacts" drop-down on the upper left.

[rivy]

@sergeevabc , I've finished a full GHA workflow to automate all builds for releases of lsd. The builds include all windows targets.

I released a PR (Peltoche/lsd#308) containing the workflow; it is pending review.

In the meanwhile, an example release (0.16.3) containing all builds is available (temporarily) from my fork.

[sergeevabc]

@rivy, I certainly appreciate your attention, but the output of lsd looks unpleasing on my end.

[rivy]

Granted. It doesn't quite meet my needs/desires either. But the point was really to point out a working Windows example that includes the functionality that exa needs. Hopefully, it can be used as a starting point to add full Windows functionality here for exa.

BTW, you might try using an alternate font, eg, one of the full Nerd Fonts. It might give you more complete and visually appealing result. My current favorite shell font that I'm using is a fully "nerd" patched version of Cascadia Code. I call it "Cascodia".

[zkat]

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!