exa is not available on Windows #32
Comments
|
There are currently three problems preventing Windows support:
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. |
|
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 There are currently three problems preventing Windows support: 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. — |
|
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 :( |
|
Just ran across If it's at all helpful, I tried installing on my machine anyway and got: I also tried installing |
|
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. |
|
@evhub I believe the errors you are getting about experimental features is because your rust compiler is out of date, try Current stable version is 1.19, see which version you are using with |
|
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. |
|
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? |
|
My attempts at building on Windows with latest stable Rust so far have resulted in a ton of errors from the |
|
Ok so right now, there's a couple dependencies that fail to compile outright on Windows:
Then there's also the fact that basically all permissions handling is also Unix-specific, which is another blocker. |
|
Note that on Windows 10, the WSL team has worked to make conhost mostly |
|
Now if they could make powershell or cmd similarly compatible... |
|
@Kethku I don't think you understand the split between shell and terminal under Windows. PowerShell and CMD both run under conhost. |
|
It might be possible to use the same approach as |
|
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" ***@***.***> 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
<#32 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ADK2722BGmQcaZsg8B8uemHFgtDasQEBks5sWZ1SgaJpZM4DknBI>
.
|
|
Sweet. #237 fixes the terminal size problem. |
|
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. |
|
For anyone interested, here's how I'm setup on Windows to call In your PowerShell profile (ie: Also, if you're on a recent build of Windows 10 (at least build 17093), I highly recommend configuring your Call from PowerShell in ConEmu: Call from vanilla PowerShell (obviously not as pretty): |
|
Is it possible to use GetNamedSecurityInfo winapi to retrieve user infos and permissions? |
|
Windows binary is still anticipated. |
This has a simple solution. 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. |
|
I'm toying around with this. Current problems I've ran into and workarounds:
I'm currently trying to figure out a quick workaround for the 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. |
|
@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 |
|
|
|
@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. |
|
You need to use |
|
@mqudsi that's what I'm using (and I'm using the |
|
@mqudsi https://github.com/zkat/exa/blob/master/src/options/parser.rs#L483-L497 Here's an example. This complains that I'm using a temporary value instead of having its lifetime be based on the input |
|
I’m on my phone but you are using to_bytes instead of as_bytes, no? |
|
That's correct -- |
|
That's not going to work, because it creates a new The OsStrBytes crate is weird. It'll force you to reference the temporary value in any return result or else copy out. I have my own snippet I use but it is unsafe; you can try it for demonstration purposes to see that it gets the job done. I think it's fundamentally safe, but I'm happy to be proven wrong. use std::ffi::{OsStr, OsString};
pub(crate) trait RawOsStr {
fn as_bytes(&self) -> &[u8];
fn from_bytes(bytes: &[u8]) -> &Self;
}
pub(crate) trait RawOsString {
fn from_bytes(bytes: Vec<u8>) -> Self;
}
impl RawOsStr for OsStr {
fn as_bytes(&self) -> &[u8] {
unsafe { std::mem::transmute(self) }
}
fn from_bytes(bytes: &[u8]) -> &Self {
unsafe { std::mem::transmute(bytes) }
}
}
impl RawOsString for OsString {
fn from_bytes(bytes: Vec<u8>) -> Self {
unsafe { std::mem::transmute(bytes) }
}
}which would give you a working solution: fn split_on_equals<'a>(input: &'a OsStr) -> Option<(Cow<'a, OsStr>, Cow<'a, OsStr>)> {
let input_bytes = input.as_bytes();
if let Some(index) = input_bytes.iter().position(|elem| *elem == b'=') {
let (before, after) = input_bytes.split_at(index);
// The after string contains the = that we need to remove.
if !before.is_empty() && after.len() >= 2 {
return Some((
OsStr::from_bytes(before).into(),
OsStr::from_bytes(&after[1..]).into(),
));
}
}
None
}fwiw, as I understand it there is talk about adding this to the standard library regardless of OS. |
|
@mqudsi I don't understand how a |
|
So far so good :) Only one test failing, and then it's time to start porting and enabling whatever bits of |
|
anyway, |
|
You don’t turn the u16 into a u8, you map it to two u16. The only concern is alignment, but that’s ok here for other reasons. You cannot make any assumptions about the contents in byte form, all it lets you do is serialize an OsString to an equivalent in-memory binary payload where the only thing you can can do with it is store it and deserialize it back. (Technically Marshall and not serialized) |
|
@zkat Great job!!! FYI I'm getting a time zone error too:
|
|
@zkat Thank you so much! It even works on a drive other than C: (as opposed to lsd). |
|
@ogham Is there anyone currently working on this feature? I'd be curious to throw my hat in the ring if it isn't already on some else's plate. |
|
Hi guys. I've created #820 for Windows support. Check that out if you're interested 😄 |
Thanks for this; I didn't know I could call bash from windows like this. 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"
} |
|
@si-kotic your enhanced version of code cannot list directories with spaces in name properly? At least from my testing it's not working though. (sorry I can't write in the PowerShell lang so can't really fix anything) |
|
#820 should close this issue. And when a new version will be released? |
|
I compiled exa on my machine and ran it at the root of a partition and got exa version 0.10.1 |
|
Any new ETA on when exa will be available on Windows? |
|
bro you definitely wanna check out lsd which stands for ls-deluxe, and it can be installed natively on Windows 11 using |
|
@seanmamasde thanks for mentioning. I'll try it out. |
|
Closing this, exa is unmaintained (see #1243), and the the active fork eza has better support for Windows than exa. |
and others
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 nouid_tinlibcC:\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 nogid_tinlibcC:\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
The text was updated successfully, but these errors were encountered: