[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Handling files with CRLF line ending

From: Koichi Murase
Subject: Re: Handling files with CRLF line ending
Date: Wed, 7 Dec 2022 11:28:54 +0900

2022年12月7日(水) 8:40 L A Walsh <bash@tlinx.org>:
> [...]  Similarly w/bash --
> I haven't tested it, but I'd expect bash compiled for windows
> (using mingw toolchain) to use CRLF, but LF for WSL or Cygwin.

I think there is actually no Bash compiled for Windows (i.e., the pure
Windows API on the Windows subsystem). The Bash that comes with the
MinGW toolchain is linked with msys-2.0.dll (in the case of MSYS2),
which means that the POSIX layer Bash relies on is provided by MSYS
which is a minimized fork of Cygwin. The MSYS Bash treats LF as the
newline but not CRLF.

> Are you using both tools for the same OS and subsys and having
> them conflict?

I think so. I think this means that the reported configuration is
wrong or, at least, very unusual. I don't think we should add in Bash
an option that is only meaningful in a specific non-unix-like
operating system for a heterogeneous amalgam of programs from
different subsystems. That option is practically useless in all of the
major Unix-like systems.

If something would be modified at the side of Bash, maybe there is a
chance that Bash of the Cygwin/MSYS packages could be patched like
`shopt -s completion_strip_exe'. But even with that case, a question
is why filtering by `tr' is not an option. The answer seemed to be to
make the program work unmodified, but I don't think we should expect
that the combination of programs from different subsystems will work
unmodified in general.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]