bug: eza.exe <file_specification> always raises "os error 123"

[RaffaeleBianc0]

• eza --version = 0.12.0
• The command-line arguments you are using: eza.exe <file_specification (varies - see screenshots)>
• Your operating system and hardware platform: Windows 11 Pro + Windows Terminal 1.17.11461.0 on HP ZBook Firefly 15 G8 PC

Hello, standard file/directory specifications, useful to filter the output, always return an "os error 123" when used. Examples (in the screenshot below):

• eza.exe t*
• eza.exe t*.*
• eza.exe "t*.*"

Same is happening when i try the "?" wildcard.

[Nemo157]

Another thing that's not supported on windows, since it's normally handled by the shell: ~, it might be that a windows glob support library will fix both at the same time, or it might be a separate issue.

[9glenda]

I'm not into windows at all but on Linux handling ~ (globbing) should always be handled by the shell since escaping ~ or * will just parse it as plain text to the command and this would break being able to escape ~ or * completely.

I don't see why this should be handheld by the command.

It would be useful to know the shell you are using (shell is not terminal) because according to a quick google search power shell does support wildcards. https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_wildcards?view=powershell-7.3

[Nemo157]

I don't see why this should be handheld by the command.

Windows shells don't handle tilde and glob expansion, they just pass the literal argument to the command (they don't even handle splitting the string up, the command gets a single string including spaces and quotes, but std splits it up for you).

PowerShell supports wildcards inside the various cmdlets, it gets passed as a string literal to them then they implement the globbing themselves:

Many cmdlets accept wildcard characters in parameter values

[ChrisDenton]

If the command does not support it itself then Powershell requires you to be explicit for nix-like expansions. E.g.:

eza (rvpa ~)

[eggbean]

Found this issue after encountering this bug. The weird thing is that I have been using an early build of exa for Windows for months and I have only noticed this now, so is it something that the old build could handle?

[cafkafk]

That's interesting, it suggests we could just git bisect our way to figuring out exactly what introduced this.

[eggbean]

@cafkafk Ah, no, sorry.. I went back in my git history and found the old binary. Same issue. I must've not used globs with it on Windows, as I usually use WSL on Windows.

[cafkafk]

ohh, rip >_<

[0017031]

See disscussion #621 File wildcard/glob patterns in Windows eza

[daviessm]

From #621: I have a branch at https://github.com/daviessm/eza/tree/clap with a fix for this issue, I'd appreciate it if others could test.

It's based on the upcoming change to the clap command line parser rather than the main code base so there may be other minor changes because of that.

[eggbean]

I tried to compile it but I get errors with gcc (scoop package). Not sure what I am doing wrong. Have you got a link to a compiled binary?

[daviessm]

If you trust me... https://github.com/daviessm/eza/releases/tag/test-0.17.2-windows-glob

[eggbean]

@daviessm I've been using it for a few hours and it seems to work fine. Excellent, thanks for fixing this deficiency🎉

[daviessm]

I'll do a PR for this once the clap changes are merged.

[robertstrom]

Hello,

I am running the latest version of eza on Windows 11 (v0.18.16 [+git] istalled via winget) and I am still seeing the behavior described above.

Wondering if there is any timeline to push the fix mentioned above on January 25th to the code distributed via winget?

Thanks

[daviessm]

Nope, still waiting for the clap PR to get merged.

[eggbean]

@daviessm Is it still not merged?

[cafkafk]

@daviessm Is it still not merged?

Last I checked it was in need of reviewers.

[daviessm]

@daviessm Is it still not merged?

Last I checked it was in need of reviewers.

Volunteers welcome!

[eggbean]

Well, I'm available to beta-test a merged build.

[davidjenni]

As a temporary workaround for Windows/PS users who wrap eza into a ls alias, here's a somewhat hacky way to emulate wildcard expansion from the calling PS shell:

Remove-Item alias:\ls -force -ErrorAction SilentlyContinue | Out-Null
function ls { param ( [string[]] [Parameter(ValueFromRemainingArguments)] $zrest )
    # hacky attempt to handle wildcard expansion by PS shell; exa expects unix-shell-like expansion before it is launched:
    # https://github.com/eza-community/eza/issues/337
    # name parameter with a letter NOT used by any eza options to avoid PS claiming that as a function parameter
    if ($($zrest.Length) -gt 0) {
        $regular = ($zrest | Where-Object { $_ -notmatch '[*\?]+' })
        $expanded = ($zrest | Where-Object { $_ -match '[*\?]+' } | Get-Item -ErrorAction SilentlyContinue | ForEach-Object { $_.Name })
    }
    eza --sort ext --group-directories-first --classify --color=auto --icons=auto $regular $expanded
}

https://github.com/davidjenni/dotfiles/blob/c67d13e00250543b63829c79b30c723f1140d822/win/profile.ps1#L115