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