3 ms·

But we do NOT need to setup CRLF translation at all? Who in his sane mind uses CRLF even under windows? All my source codes are in UNIX format (aka LF only) and

by Borg3 1y ago

But we do NOT need to setup CRLF translation at all? Who in his sane mind uses CRLF even under windows? All my source codes are in UNIX format (aka LF only) and I use it consistent under Windows, Cygwin and UNIX.. Why make your life harder?

saghm 1y ago
I think the issue is that people don't make their own lives harder, but sometimes they make the lives of other people harder (often unintentionally). In my experience, the CRLF files I run into tend to come from developers who are only working in Windows and either aren't aware of the issue or don't particularly care to do anything about it. It isn't something I run into often when cloning a git repo, but having recently started dabbling in the world of mod development for games, there's a lot of stuff out there that seemingly has never been touched by someone who's used Linux before. To be clear, I don't blame anyone for this, since people working on things for free in their spare time shouldn't have to worry about anything other than what interests them, but it's a bit amusing to me that I sometimes have less to configure to run an .exe on Linux than I do to start editing the source for it in a way that makes it easy for me to merge any new changes that happen upstream.
- 1718627440 1y ago
  > I sometimes have less to configure to run an .exe on Linux than I do to start editing the source for it in a way that makes it easy for me to merge any new changes that happen upstream. Are you doing anything more than calling dos2unix?
mathiaspoint 1y ago
The language runtime will insert/remove CR for you if you open the file in text mode on Windows. You'd be surprised how much stuff cygwin itself actually does for you. If your code isn't too Linux specific try building it under mingw instead and you can see what's actually going on.
- Borg3 1y ago
  Cygwin does NOTHING under the hood, because I asked it to do nothing. I am aware of text mode of open() under Windows/Mingw. Im also aware of possibility to do CRLF <-> LF translation under cygwin. I never liked it, and I went to LF only quickly. Hence, I use it everywhere and live is easier :)
aleph_minus_one 1y ago
> Who in his sane mind uses CRLF even under windows? All my source codes are in UNIX format (aka LF only) and I use it consistent under Windows, Cygwin and UNIX.. Why make your life harder? Why would you use LF if the focus of the application that you develop is Windows? You make the life harder for these users. :-) Seriously: your argument typically comes from developers who consider GNU/Linux as a first-class citizen as a development or deployment platform, and Windows only as a second-class citizen (assuming that a Windows port actually exists). I can accept an argument like "I, as a developer, don't care about Windows and its users, so all my source code is in UNIX format." This is a conscious, though quite political decision. But an argument like "not using LF makes lifes harder" without a relativization on which premises this claim is build (such as "GNU/Linux and macOS users are much more important for as, and if there exist any users or developers who use Windows, we consider them to be undesired, because they make everybody's lifes harder") is intellectual ignorance.
- python-b5 1y ago
  Using LF on Windows is really not difficult. Any text editor actually worth using supports both types of line endings - even Notepad has handled this correctly for years now, from what I remember. I've never been caused any inconvenience as a Windows user by files with LF endings. I never use CRLF if I can avoid it; I only will if working on a codebase that already uses it throughout.
- Borg3 1y ago
  Oh, its simple. There are many many flavors of UNIX and only one Windows. Hence, I see LF as more portable way to store source code, thats why it is prefered. Additionally, im heavy CLI user so again, more geared toward UNIX systems. If you develop on windows and only for windows, use CRLF all the way. Just do NOT forget to set .gitattributed correctly, and you are set.
  - aleph_minus_one 1y ago
    > There are many many flavors of UNIX and only one Windows. With ReactOS, there even exists a flavor that is not developed by Microsoft. If you consider Wine and its derivates as an implementation of the WinAPI, you have one additional (or multiple if you consider their derivates) implementation of the WinAPI. Even if you only consider the flavours of Microsoft Windows that are full operating systems, you immediately get multiple ones: - the discontinued Win 9x series - the discontinued Windows CE, Windows Embedded CE, Windows Embedded Compact, Windows Mobile, Windows Pocket series (technically quite different from both Windows 9x and Windows NT) - Lots of variants (indirectly) derived from Windows NT: * Windows (desktop OS) * Windows Server * Windows IoT (I would claim that at least for the Windows 10 IoT Core version, the user experience is quite different from both desktop and server Windows) * Windows PE [1] * Further discontinued variants such as Windows Phone [1] https://en.wikipedia.org/wiki/Windows_Preinstallation_Environment https://en.wikipedia.org/wiki/Windows_Preinstallation_Enviro...
jibal 1y ago
The ability to do that is a recent development. And numerous programming environments still default to adding CRLF and stripping it off when running on Windows, and all the system tools on Windows generate files with CRLF as line terminators so all software needs to deal with them.
chuckadams 1y ago
> Who in his sane mind uses CRLF even under windows? Hopefully nobody is using it for documents, but most text-based internet protocols, including SMTP and HTTP, use CRLF for line endings.
rswail 1y ago
I fully agree, but we're talking history here, before Unix existed. The confusion about "LF" (Unix) vs "CR" (Apple) vs "CR/LF" (MS/DOS & Windows) is because we didn't have an explicit "Line End" character in 7-bit ASCII. There was "EOT" (Ctrl-D/ASCII 4/EOF in Unix) , "ETX" (Ctrl-C/ASCII 3), and other characters that were used to mean other I/O, including ones that didn't match the ASCII definition like Ctrl-S/Ctrl-Q to stop/start I/O, and Ctrl-Z to mean EOF (MS/DOS & Windows).

by Borg3 1y ago

saghm 1y ago

I think the issue is that people don't make their own lives harder, but sometimes they make the lives of other people harder (often unintentionally). In my experience, the CRLF files I run into tend to come from developers who are only working in Windows and either aren't aware of the issue or don't particularly care to do anything about it. It isn't something I run into often when cloning a git repo, but having recently started dabbling in the world of mod development for games, there's a lot of stuff out there that seemingly has never been touched by someone who's used Linux before. To be clear, I don't blame anyone for this, since people working on things for free in their spare time shouldn't have to worry about anything other than what interests them, but it's a bit amusing to me that I sometimes have less to configure to run an .exe on Linux than I do to start editing the source for it in a way that makes it easy for me to merge any new changes that happen upstream.

1718627440 1y ago
> I sometimes have less to configure to run an .exe on Linux than I do to start editing the source for it in a way that makes it easy for me to merge any new changes that happen upstream. Are you doing anything more than calling dos2unix?

mathiaspoint 1y ago

The language runtime will insert/remove CR for you if you open the file in text mode on Windows. You'd be surprised how much stuff cygwin itself actually does for you. If your code isn't too Linux specific try building it under mingw instead and you can see what's actually going on.

Borg3 1y ago
Cygwin does NOTHING under the hood, because I asked it to do nothing. I am aware of text mode of open() under Windows/Mingw. Im also aware of possibility to do CRLF <-> LF translation under cygwin. I never liked it, and I went to LF only quickly. Hence, I use it everywhere and live is easier :)

aleph_minus_one 1y ago

> Who in his sane mind uses CRLF even under windows? All my source codes are in UNIX format (aka LF only) and I use it consistent under Windows, Cygwin and UNIX.. Why make your life harder? Why would you use LF if the focus of the application that you develop is Windows? You make the life harder for these users. :-) Seriously: your argument typically comes from developers who consider GNU/Linux as a first-class citizen as a development or deployment platform, and Windows only as a second-class citizen (assuming that a Windows port actually exists). I can accept an argument like "I, as a developer, don't care about Windows and its users, so all my source code is in UNIX format." This is a conscious, though quite political decision. But an argument like "not using LF makes lifes harder" without a relativization on which premises this claim is build (such as "GNU/Linux and macOS users are much more important for as, and if there exist any users or developers who use Windows, we consider them to be undesired, because they make everybody's lifes harder") is intellectual ignorance.

python-b5 1y ago
Using LF on Windows is really not difficult. Any text editor actually worth using supports both types of line endings - even Notepad has handled this correctly for years now, from what I remember. I've never been caused any inconvenience as a Windows user by files with LF endings. I never use CRLF if I can avoid it; I only will if working on a codebase that already uses it throughout.
Borg3 1y ago
Oh, its simple. There are many many flavors of UNIX and only one Windows. Hence, I see LF as more portable way to store source code, thats why it is prefered. Additionally, im heavy CLI user so again, more geared toward UNIX systems. If you develop on windows and only for windows, use CRLF all the way. Just do NOT forget to set .gitattributed correctly, and you are set.
- aleph_minus_one 1y ago
  > There are many many flavors of UNIX and only one Windows. With ReactOS, there even exists a flavor that is not developed by Microsoft. If you consider Wine and its derivates as an implementation of the WinAPI, you have one additional (or multiple if you consider their derivates) implementation of the WinAPI. Even if you only consider the flavours of Microsoft Windows that are full operating systems, you immediately get multiple ones: - the discontinued Win 9x series - the discontinued Windows CE, Windows Embedded CE, Windows Embedded Compact, Windows Mobile, Windows Pocket series (technically quite different from both Windows 9x and Windows NT) - Lots of variants (indirectly) derived from Windows NT: * Windows (desktop OS) * Windows Server * Windows IoT (I would claim that at least for the Windows 10 IoT Core version, the user experience is quite different from both desktop and server Windows) * Windows PE [1] * Further discontinued variants such as Windows Phone [1] https://en.wikipedia.org/wiki/Windows_Preinstallation_Environment https://en.wikipedia.org/wiki/Windows_Preinstallation_Enviro...

jibal 1y ago

The ability to do that is a recent development. And numerous programming environments still default to adding CRLF and stripping it off when running on Windows, and all the system tools on Windows generate files with CRLF as line terminators so all software needs to deal with them.

chuckadams 1y ago

> Who in his sane mind uses CRLF even under windows? Hopefully nobody is using it for documents, but most text-based internet protocols, including SMTP and HTTP, use CRLF for line endings.

rswail 1y ago

I fully agree, but we're talking history here, before Unix existed. The confusion about "LF" (Unix) vs "CR" (Apple) vs "CR/LF" (MS/DOS & Windows) is because we didn't have an explicit "Line End" character in 7-bit ASCII. There was "EOT" (Ctrl-D/ASCII 4/EOF in Unix) , "ETX" (Ctrl-C/ASCII 3), and other characters that were used to mean other I/O, including ones that didn't match the ASCII definition like Ctrl-S/Ctrl-Q to stop/start I/O, and Ctrl-Z to mean EOF (MS/DOS & Windows).