When running ls with a glob pattern that uses forward slashes (for example, c:/Windows/*.exe), the output paths are normalized to backslashes instead of preserving the separator style used in the input pattern.
This makes the output inconsistent with the command that was typed, and it can break scripts or tools that parse ls output and expect the path format to remain stable.
Steps to Reproduce
C:\Windows> ls c:/Windows/*.exe
Actual Output
'c:/Windows\HelpPane.exe'
'c:/Windows\bfsvc.exe'
'c:/Windows\notepad.exe'
'c:/Windows\write.exe'
...
Expected Output
'c:/Windows/HelpPane.exe'
'c:/Windows/bfsvc.exe'
'c:/Windows/notepad.exe'
'c:/Windows/write.exe'
...
Why This Matters
The output should be consistent with the path style used in the input glob pattern. When ls output is used for programmatic parsing, the unexpected separator conversion can cause parsing failures or make downstream processing more difficult.
Environment
- OS: Windows
- Shell: Command Prompt (cmd.exe)
- coreutils version: ls (uutils coreutils) 0.8.0
Comparison with WSL
For reference, ls under WSL does not show this issue in the same way:
user@pc:/mnt/c/Users/USER$ ls /mnt/c/Windows/*.exe
/mnt/c/Windows/HelpPane.exe /mnt/c/Windows/explorer.exe /mnt/c/Windows/notepad.exe /mnt/c/Windows/splwow64.exe
/mnt/c/Windows/bfsvc.exe /mnt/c/Windows/hh.exe /mnt/c/Windows/regedit.exe /mnt/c/Windows/winhlp32.exe
This makes the Windows build look inconsistent compared with the WSL behavior for the same kind of globbed output.
Additional Note
I could not find an existing issue for this specific behavior.
When running
lswith a glob pattern that uses forward slashes (for example,c:/Windows/*.exe), the output paths are normalized to backslashes instead of preserving the separator style used in the input pattern.This makes the output inconsistent with the command that was typed, and it can break scripts or tools that parse
lsoutput and expect the path format to remain stable.Steps to Reproduce
C:\Windows> ls c:/Windows/*.exeActual Output
Expected Output
Why This Matters
The output should be consistent with the path style used in the input glob pattern. When
lsoutput is used for programmatic parsing, the unexpected separator conversion can cause parsing failures or make downstream processing more difficult.Environment
Comparison with WSL
For reference,
lsunder WSL does not show this issue in the same way:user@pc:/mnt/c/Users/USER$ ls /mnt/c/Windows/*.exe /mnt/c/Windows/HelpPane.exe /mnt/c/Windows/explorer.exe /mnt/c/Windows/notepad.exe /mnt/c/Windows/splwow64.exe /mnt/c/Windows/bfsvc.exe /mnt/c/Windows/hh.exe /mnt/c/Windows/regedit.exe /mnt/c/Windows/winhlp32.exeThis makes the Windows build look inconsistent compared with the WSL behavior for the same kind of globbed output.
Additional Note
I could not find an existing issue for this specific behavior.