Skip to content
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

Merged
merged 27 commits into from
Feb 20, 2023
Merged

Initial support for Windows #820

merged 27 commits into from
Feb 20, 2023

Conversation

skyline75489
Copy link
Contributor

Supports #32

@skyline75489
Copy link
Contributor Author

skyline75489 commented Mar 26, 2021

This PR is based on previous work by @zkat (see #32 (comment)). All the tests is green. This is what it looks like now:

exa-windows

There are still things that need to be fixed, of course. For example git does not seem to work Git works now but timezone detection does not work. If the author want this, I'd like to continue improving the support for Windows.

@skyline75489
Copy link
Contributor Author

Hi @ariasuni can I get a little help with the CI build? I've test it myself. It works on both Windows & Linux.

@ariasuni
Copy link
Collaborator

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 size functions with the cfg attributes, or


I suppose that afterwards I should set:

os:
  - linux
  - windows

in .travis.yml on master branch?

@skyline75489
Copy link
Contributor Author

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 😄

@skyline75489
Copy link
Contributor Author

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.

@djdv
Copy link

djdv commented Mar 28, 2021

Just a heads up, the --git parameter works for conventional paths 🎉, but doesn't seem to work when the path is a UNC path (such as a network share).
I'm not familiar enough with exa (or Rust) to know where the path from reorient is being used, but it may be such that the prefix \\?\... has to be preserved in these cases, but stripped when the path is something like \\?\X:\....
But that's just a guess.

Here is a side-by-side:
exa git

For context, pwd.exe is GNU's pwd and pwd is Powershell's own builtin.
(I should also say that for me personally this isn't a big deal, but I noticed the patch and wanted to check that case. Figured this would be good to know)

@skyline75489
Copy link
Contributor Author

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.

@ogham
Copy link
Owner

ogham commented Mar 30, 2021

This is really cool! Although the --long output looks really, really different from what I expect exa to look like :)

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 --no-permissions argument, and the help text, so it's not quite as simple as changing it in one place.

I'm willing to add UNC path support later because supporting Windows is already such a big jump.

@ogham
Copy link
Owner

ogham commented Mar 30, 2021

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.

@skyline75489
Copy link
Contributor Author

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

@sergeevabc
Copy link

Err… Would you mind attaching a final Windows binary here or somewhere nearby, please?

@skyline75489
Copy link
Contributor Author

@ogham I have some thoughts about the permission as well. I would love to make it the same as Mode in PowerShell (see link. I assume this needs win32 APIs.

The timezone detection logic is also a missing piece. I haven't done the investigation but I assume we'll also need Win32 API for that.

@skyline75489
Copy link
Contributor Author

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

@skyline75489
Copy link
Contributor Author

OK I managed to implement "permission" to mimic the "mode" in PowerShell. Here's how it looks:

image

PowerShell gci result for reference:

image

@ogham
Copy link
Owner

ogham commented Mar 30, 2021

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.

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.

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.

@scottbilas
Copy link

scottbilas commented Aug 23, 2022

...and Powershell also follows this convention...

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 exa *.cpp??")

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

@scottbilas
Copy link

@scottbilas Interesting note, ls under WSL2 can handle the directories, but not the files

Yeah same here. Never noticed it before..

A tiny bit more info on the problem at athityakumar/colorls#297 (comment)

@garyo
Copy link

garyo commented Aug 23, 2022

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.

@amrbashir
Copy link

amrbashir commented Aug 23, 2022

there is also the wild crate which mimics the unix expansion for windows and used by uutils/coreuitls

// 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('_') {
Copy link

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.

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.

Copy link

@ntpeters ntpeters Oct 7, 2022

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

Copy link

@bitzl bitzl left a 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.

@ariasuni
Copy link
Collaborator

OK, I will merge it then. Please open issues for unfinished, buggy or missing stuff, so that we can improve Windows support!

@ariasuni ariasuni merged commit f3ca1fe into ogham:master Feb 20, 2023
@AntoniosBarotsis
Copy link

AntoniosBarotsis commented Feb 20, 2023

@ariasuni About the failing workflow, cargo-hack seems to specify rustc v1.60, you are using 1.56.

It might make sense to add fail-fast: false to allow all parts of the job matrix to execute instead of being cancelled to have a better idea of what went wrong if a run fails (in this case, everything except for 1.56 should've passed for instance).

@ariasuni
Copy link
Collaborator

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 fail-fast: false wouldn’t change a thing since there’s only one job each time.

@AntoniosBarotsis
Copy link

fail-fast should make all jobs run regardless of whether the first one failed. By all jobs I mean the same tasks in the different OSes you defined in your matrix.

@eggbean
Copy link

eggbean commented Apr 3, 2023

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.

@specter119
Copy link

specter119 commented Apr 6, 2023

@eggbean exa --color=never got the no color result on my windows machine. however, I still build based on https://github.com/skyline75489/exa/tree/chesterliu/dev/win-support

@eloc3147
Copy link

@eggbean I saw your comment in #1133
When you're piping into less, are you running in mingw? I don't have less in command prompt or powershell

@ntpeters
Copy link

ntpeters commented May 26, 2023

I also can't repro the color issue when piping to less on Windows. Piping with (--color=always) or without color (--color=never) shows correctly in less, although the colors do get munged a bit.
I'm running the Windows build of less installed via scoop from here, and also still running the same build of exa that @specter119 noted.

@eggbean
Copy link

eggbean commented May 28, 2023

@eggbean I saw your comment in #1133

When you're piping into less, are you running in mingw? I don't have less in command prompt or powershell

I'm using cmd.exe (with clink) and the less version in busybox (scoop package).

@eloc3147
Copy link

I also cannot reproduce this color issue using:

  • Clink v0.4.9 [git:2fd2c2]

  • Less from BusyBox v1.37.0-FRP-5007-g82accfc19 (2023-05-28 11:00:58 BST)
    (mingw64-gcc 12.2.1-8.fc38; mingw64-crt 10.0.0-4.fc38; glob)

  • Exa c697d06

exa and exa --color=never both do not emit color codes to less, only exa --color=always does.

@eggbean
Copy link

eggbean commented May 31, 2023

@eloc3147 I probably have an older build?

C:\Windows\System32>exa --version
exa - list files on the command-line
v0.10.1 [+git]
https://the.exa.website/

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.

@eggbean
Copy link

eggbean commented May 31, 2023

If I install rust, how do I get the relevant code to compile?

@eloc3147
Copy link

eloc3147 commented Jun 1, 2023

@eggbean
That was my google drive link ;) I've tested that (older) build and it also behaves correctly when piped.

To build:

  • Clone this repo git clone https://github.com/ogham/exa
  • Open the repo dir cd exa
  • If you want to just build: cargo build
  • If you want to build and install into your path: cargo install --path .

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.

@eggbean
Copy link

eggbean commented Jun 5, 2023

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 winget install -e Rustlang.Rust.MSVC but it doesn't give me cargo and I cannot find it in the winget repository. Would prefer to use winget if I can.

@eloc3147
Copy link

eloc3147 commented Jun 5, 2023

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 Rustlang.Rustup, this will install all the default tools and allow you to manage your rust version(s).

@SillyCatto
Copy link

SillyCatto commented Jun 12, 2023

I compiled exa on my machine and ran it at the root of a partition and got some Access denied os error 5 errors on some files and folders. I tried to ignore them with --ignore-globs="" but it doesn't work.

exa version 0.10.1
Win10 22H2

2

@AndreM222
Copy link

how is the setup for windows powershell and will it work with terminal-icons?

@ariasuni
Copy link
Collaborator

ariasuni commented Sep 6, 2023

exa is unmaintained (see #1243), and Windows support is better in the active fork eza, please check it out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.