Skip to content

fix: strip trailing separators from path args on Windows - #1950

Open
GhostCoder6969 wants to merge 1 commit into
eza-community:mainfrom
GhostCoder6969:fix-trailing-separator-args-404
Open

GhostCoder6969 wants to merge 1 commit into
eza-community:mainfrom
GhostCoder6969:fix-trailing-separator-args-404

Conversation

@GhostCoder6969

Copy link
Copy Markdown
Description

Fixes #404. On Windows the fs calls reject a path like C:\Program Files\ with OS error 123, so I normalize CLI path arguments through their components before anything touches the filesystem. Roots (/, C:\) survive the round trip, and outside Windows the argument passes through byte-identical.

How Has This Been Tested?

I could not repro the Windows error on Linux, so I verified the normalization logic with unit tests (trailing separators go, roots stay) plus the full cargo test suite, cargo fmt --check, and zero-warning cargo clippy. The Windows CI job should show the original command listing the directory. Happy to adjust the approach if you would rather fix this deeper in File.

No new flags, so no completions, man, README, or help changes needed. Commit follows conventional commits with Closes #404.

Filesystem calls reject paths like 'C:\Program Files\' with OS error 123, so normalize CLI path arguments through their components before use. Roots are kept intact and behavior outside Windows is unchanged.

Closes eza-community#404
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.

bug: Windows OS error 123 when passing a path spec with long file names to eza in PowerShell

1 participant