-
-
Notifications
You must be signed in to change notification settings - Fork 661
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Initial support for Windows #820
Initial support for Windows #820
Conversation
This PR is based on previous work by @zkat (see #32 (comment)). All the tests is green. This is what it looks like now: There are still things that need to be fixed, of course. |
Hi @ariasuni can I get a little help with the CI build? I've test it myself. It works on both Windows & Linux. |
I suppose the compilation error is due to the fact the CI uses Rust 1.42.0. Are you able to locally build exa with this version of Rust? If that’s the problem, you can just write two different I suppose that afterwards I should set:
in |
Hi @ariasuni Thanks for the feedback! I've fixed the build. I'm like a true newbie of rust. Please double check to make sure I'm not doing anything stupid 😄 |
As for the CI build, it would be nice to have a Windows job. Also I'm honestly OK with not having at the moment, since the Windows support is still very initial. Passing the tests does not really mean the experience on Windows is good enough. |
Just a heads up, the For context, |
thanks @djdv for the heads up. I do understand that the code currently won’t work with UNC paths and I plan to add support for UNC paths in the future. Right now I just want to build the basics things on Windows and start from there. |
This is really cool! Although the On that note, I think it's worth changing the name of the left-most column. I only named it "Permissions" because I knew its Unix output was going to be ten or more characters wide. Now it's just one, it looks strange to me with that long header name with all the space there — none of the other columns change their width so drastically when the header is added. Of course, that affects things like the I'm willing to add UNC path support later because supporting Windows is already such a big jump. |
About the use of Rust 1.42: the MSRV is specified in the README and the Travis check is just there to check it doesn't go out-of-date, but I'm not tied to that particular version. If you need a feature from a later one then I'd be happy to bump it. |
@ogham thanks so much for this amazing software. I’m finally able to have a unified ls experience across different systems and I am glad to help the community, even though i’m a rust newbie 😃 |
Err… Would you mind attaching a final Windows binary here or somewhere nearby, please? |
@sergeevabc I think in the future we can put a binary in the release page once the Windows support is merged and the next release is available. At the moment the Windows support is still initial. If you really want to try it, feel free to checkout my branch and compile it. |
Ah, "Mode" is much better! I'm glad there's a precedent for it in Powershell, so the column can contain the flags that people expect.
Yeah; I had to set up a Windows VM for testing one of my other projects. I can use it to compile Windows exa and make it part of the release when the time comes. |
Powershell has some weak support for a couple shell-expansion-ish features (like ~ and *), but a crucial limitation is that it only does this on internal commands, and not on processes it launches. I'd guess this is because of compatibility with Windows native cli tools that are expecting to get raw wildcards in their args. Anyway, the bottom line is that this kind of thing does not work on Windows: exa ~
exa /Prog*
exa FooB?r (Let's not even mention the rich expressions that a shell like zsh supports..) Any port of a unix-first CLI tool to Windows will hit this impedance mismatch and then be stuck with either a) duplicating a portion of bash's basic expansion features like globbing, just for Windows (yuck), or b) leave the Windows port with an unhappy surprise ("huh, I can't do I guess the "right" solution would be to find a Powershell module that can glob-expand, and direct users to write little helper functions that route calls through that to unix-first CLI tools where such processing makes sense (like exa). |
Yeah same here. Never noticed it before.. A tiny bit more info on the problem at athityakumar/colorls#297 (comment) |
Using a shell-glob library (e.g. https://github.com/p-ranav/glob) is a fine idea, but note that some users (like me) will almost always be using it from within msys or cygwin anyway, and running a "real" shell, so in that case the current version is fine because the shell expands the wildcards. |
there is also the |
// Also hide _prefix files on Windows because it's used by old applications | ||
// as an alternative to dot-prefix files. | ||
#[cfg(windows)] | ||
if ! self.dotfiles && filename.starts_with('_') { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is overdoing it. Python uses __init__.py
for top-level modules, and this hides all such files. If you're running this build with msys/cygwin, most likely your dotfiles actually start with '.' anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know any files, except for _vimrc
on Windows that follows this convention either.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you're running this build with msys/cygwin, most likely your dotfiles actually start with '.' anyway
Even without msys/cygwin. I don't mess with those and only use pwsh, and just use the normal dot prefix for all my dotfiles (including .vimrc).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me. I think this should be merged as is, and if there might be any further comments or issues, these should be a new PR since this one is already huge.
OK, I will merge it then. Please open issues for unfinished, buggy or missing stuff, so that we can improve Windows support! |
@ariasuni About the failing workflow, It might make sense to add |
Yeah, there’s #1125 for the upgrade of the Rust version (if it takes too long or if I have the motivation to open my code editor soon, I’ll make my own commit). Using |
|
I can't see this mentioned anywhere, but I apologise if it has: when piping to less or whatever, exa on Windows always shows colour, no matter what options are used. |
@eggbean |
I also can't repro the color issue when piping to less on Windows. Piping with ( |
I also cannot reproduce this color issue using:
|
@eloc3147 I probably have an older build?
I got it from someone here, downloaded from their Google Drive. Could I try what you have there, or where did you get it from? I don't really want to install rust on Windows. |
If I install rust, how do I get the relevant code to compile? |
@eggbean To build:
No magic here, just a standard rust project build. No special setup should be needed. If you can repro this issue with your own build, it's probably time to open a dedicated issue. |
Ha, yes it was you 🤭 I have a bit of a low-disk space situation going on with my Windows laptop and haven't taken the time to sort it out, hence the delay. How to you even install cargo on Windows? I have found and installed rust with |
The recommended way of installing rust is with rustup I find installing programming languages with the OS supplied package manager is almost always a bad idea, but if you must use winget, the package you want is |
how is the setup for windows powershell and will it work with terminal-icons? |
exa is unmaintained (see #1243), and Windows support is better in the active fork eza, please check it out. |
Supports #32