Issue 1: Unstripped ANSI escape color codes in output text
When running fselect --help or command output, raw ANSI escape sequences are printed as plain text instead of being parsed/rendered properly on Windows terminals.
The leaked sequences include:
�[33m (yellow text start)
�[0m (color reset)
�[4;36m (cyan underline start)
Example raw output snippet:
plaintext
fselect �[33m0.10.2�[0m
Find files with SQL-like queries.
�[4;36mhttps://github.com/jhspetersson/fselect�[0m
These color control characters pollute plain text output when redirecting results to .txt files or processing via batch/PowerShell scripts, breaking automated workflows.
Expected behavior:
Automatically disable ANSI color escape sequences when output is redirected to a file / non-interactive pipe on Windows;
Strip raw escape codes completely for plain text outputs without color support.
Issue 2: Output uses Unix LF line breaks instead of Windows CRLF
All text output (standard output, file exports via into csv / into lines / into json) uses Unix-style single line feed \n (LF) as newline delimiter on Windows OS, instead of Windows native \r\n (CRLF).
Problems caused:
Text files saved from fselect output display broken line wrapping in Notepad (Windows default editor cannot recognize LF newlines);
Batch / CMD / PowerShell for-loop file reading logic fails to parse line-by-line correctly;
Exported CSV/HTML lists have malformed line breaks for Windows office tools.
Expected behavior:
Detect Windows operating system automatically;
Use CRLF \r\n as line separator for all standard output and file exports on Windows;
Keep LF \n for Linux/macOS as original behavior.
Environment Info
OS: Windows 10 / Windows 11
fselect version: 0.10.2
Terminal: Windows Command Prompt (cmd.exe), PowerShell 7
2. Supplementary brief version (short comment for quick reply)
Two critical Windows output compatibility bugs in v0.10.2:
Raw ANSI color escape codes like �[33m / �[0m / �[4;36m are printed in plain text when running fselect --help or redirecting output, contaminating script file exports.
All output uses Unix LF (\n) newlines rather than Windows CRLF (\r\n), leading to unreadable text in Notepad and broken batch/PowerShell line iteration.
Request: Auto strip ANSI codes for non-TTY outputs, and switch line endings to CRLF on Windows platform.
Issue 1: Unstripped ANSI escape color codes in output text
When running fselect --help or command output, raw ANSI escape sequences are printed as plain text instead of being parsed/rendered properly on Windows terminals.
The leaked sequences include:
�[33m (yellow text start)
�[0m (color reset)
�[4;36m (cyan underline start)
Example raw output snippet:
plaintext
fselect �[33m0.10.2�[0m
Find files with SQL-like queries.
�[4;36mhttps://github.com/jhspetersson/fselect�[0m
These color control characters pollute plain text output when redirecting results to .txt files or processing via batch/PowerShell scripts, breaking automated workflows.
Expected behavior:
Automatically disable ANSI color escape sequences when output is redirected to a file / non-interactive pipe on Windows;
Strip raw escape codes completely for plain text outputs without color support.
Issue 2: Output uses Unix LF line breaks instead of Windows CRLF
All text output (standard output, file exports via into csv / into lines / into json) uses Unix-style single line feed \n (LF) as newline delimiter on Windows OS, instead of Windows native \r\n (CRLF).
Problems caused:
Text files saved from fselect output display broken line wrapping in Notepad (Windows default editor cannot recognize LF newlines);
Batch / CMD / PowerShell for-loop file reading logic fails to parse line-by-line correctly;
Exported CSV/HTML lists have malformed line breaks for Windows office tools.
Expected behavior:
Detect Windows operating system automatically;
Use CRLF \r\n as line separator for all standard output and file exports on Windows;
Keep LF \n for Linux/macOS as original behavior.
Environment Info
OS: Windows 10 / Windows 11
fselect version: 0.10.2
Terminal: Windows Command Prompt (cmd.exe), PowerShell 7
2. Supplementary brief version (short comment for quick reply)
Two critical Windows output compatibility bugs in v0.10.2:
Raw ANSI color escape codes like �[33m / �[0m / �[4;36m are printed in plain text when running fselect --help or redirecting output, contaminating script file exports.
All output uses Unix LF (\n) newlines rather than Windows CRLF (\r\n), leading to unreadable text in Notepad and broken batch/PowerShell line iteration.
Request: Auto strip ANSI codes for non-TTY outputs, and switch line endings to CRLF on Windows platform.