Why do I have to manually for every file change "CRLF" to "LF" to make eslint(prettier) warning go away?.
Can there be a problem with this approach when committing and other users load the file in their respective environment. As you see on the image I get "eslint": "^6.6.0" complaint and when I toggle the down right "CRLF" to "LF" then eslint(prettier) is happy.
Can this be a problem later?
Line breaks are traditionally represented by two bytes (CR and LF) on DOS/Windows systems, and by only one (LF) on Unix/Linux systems. The rule you're seeing, documented for eslint here and for prettier here defaults to saying that all files should use the Unix convention (saying "delete CR" is equivalent to saying "convert CRLF to LF only") to ensure the code base is consistent.
If all your files are currently CRLF, you have two options:
Configure eslint/prettier to standardise on "crlf" / "windows" instead (or disable the rule completely).
Change the line endings on your files from CRLF to LF. That could be file by file using the setting you show, by running a command-line tool like dos2unix, or by configuring prettier to fix the problem automatically.
As well as fixing your existing files, you might want to look at why they're showing up that way:
Ensure VSCode is configured to create new files with Unix / LF line endings by default
git has a "feature" that by default checkouts created on Windows will convert LF to CRLF every time you checkout, and convert them back when you commit. Since any decent code editor will cope with LF line endings just fine (even Notepad supports them now!) you should turn this off with git config core.autocrlf false
As for how this will affect other people:
If you change the line endings of files in a shared repo, this will show up as a change to every line in the version history. This is mostly a one-off nuisance, and creates a bit of noise when you're looking at the history of a file.
In the unlikely scenario someone's opening the file in a tool that only supports CRLF line endings, they'll have problems opening it. They can work around it with the above-mentioned core.autocrlf setting, or by using a better tool.
Related
Intro
There is a "feature" in Windows that adds a carriage return character before every newline. This is an old thing, but I am having trouble finding specific solutions to the problem.
Problem
If you create a file in Windows with fopen("file.txt", "w"), it will create a text file where every \n in your code is converted to \r\n. This creates a problem in situations where you try to read the file on Linux, because there is now an unaccounted-for character in the mix, and most line reads depend on reading to \n.
Research
I created text ("w") and binary ("wb") files on Windows and Linux, and tried to read and compare them with the same files made on the other OS.
Binary files do not get an added carriage return, and seem to work fine.
Text files, on the other hand, are a mixed bag:
On Windows, comparing the Windows text file (\r\n) to the Linux text file (\n) will result in them being read equally (this is apparently a feature of some C Windows implementations - \r\n will get automatically read as \n)
On Linux, comparing the files will result in them not being equal and the \r will not be handled, creating a reading problem.
Conclusion
I would like to know of ways how to handle this so my text files can be truly cross-platform. I have seen a lot of posts about this, but most have mixed and opposing claims and almost none have specific solutions.
So please, can we solve this problem once and for all after 40 years? Thank you.
Is there a way to detect the OS where the C code is compiled to handle with it's specific line break characters in text files? For example I compile my code on a Windows machine, it should use \r\n as line break in text files, on Linux it should just use \n.
I need this for a program which should read text files binary and match substrings of the file with other strings. This should work on windows and Linux.
Thanks for your help!
You don't need to know the native storage format. When reading a file, you cannot know if it was created on a Window, Linux, or other system -- it could be created on another system than the one you are working on. When writing, your program will use the native libraries for your OS and output whatever it deems appropriate for \n.
Reading a text file line-ending agnostically comes down to this:
use a binary mode rather than "text mode" (you seem to already do this).
read text until you encounter either an \r or \n.
if you get an \r, skip all next \n;
if you get an \n, skip all next \r.
This will work for line endings of \n (Linux and other Unix-like OSes such as Mac OS X), Windows-like \r\n and older Mac OS files ending with \r only. That covers about 99.99% of all "normal" text files you are likely to encounter. There used to be a very rare one that used \r\n\n (or possibly \n\r\r) but even that will be handled correctly.
The best way would be to check for a predefined macro and #ifdef on it.
You can print all the predefined MACROs using the command
gcc -dM -E - < /dev/null
and grep for "LINUX" or "WIN32"
I'd expect to find _ LINUX _ defined on Linux machines and _ WIN32 _ defined on windows machine.
We are using ClearCase UCM INTEROP setup in our organization.
We are facing a strange issue where the file content in put on one line while doing a merge and hence causing the build to fail.
Does anyone know why this is happening?
There is another thing that can sneak up and bite you here.
View text modes -- there are 3 for ClearCase, and you can get unexpected results if you use the wrong 2.
Those modes are:
insert_cr (also known as msdos). This inserts carriage returns on cleartext creation (file open/edit/etc.) and strips them at checkin.
transparent. Doesn't make any changes to the line terminations.
strip_cr. This converts Windows line terminations to Unix ones on cleartext creation. It then re-inserts them on checkin.
If you use strip_cr for unix views, and insert_cr for Windows ones, you will have all kinds of line termination issues. And in some cases this can break builds.
You need to use the 2 that are adjacent to one another on the list above. With Windows using either insert_cr and unix "transparent". Or Windows "transparent" and unix strip_cr.
You may want to look at the problem file in another editor (notepad++ is one that handles both line termination styles well) and see whether you have Unix or Windows line terminations.
It would also help to know the platform where the merge was attempted. If it was done on Windows, then #VoC's steps will work as they call the Windows GUI text merge tool. You may want to try the same thing using the Windows/Unix CLI merge tool (cleardiff) if the files are "text_file" elements. We have seen cases where the 2 CLI and GUI merge tools behave differently.
It depends on:
what "put on one line while doing a merge" means (extra line added, or the all text is in one line, which would mean \n isn't treated as a newline character)
the type of file being merge (text, xml, binary, ...), as the merge manager involved would differ.
Start by trying to reproduce the issue, as explained in this technote:
Copy the "base" version into base.txt.
Copy the "from" version into from.txt and copy the "to" version into to.txt.
Run the following command:
cleardiffmrg -out foo.out -base base.txt from.txt to.txt
See if ignoring whitespaces helps:
cleardiffmrg -blank_ignore -out foo.out -base base.txt from.txt to.txt.
Check your text modes associated with the view in which you are doing the merge.
Try and make sure the newline sequence used in both versions of the file is the same (\n for instance, both in Windows and Unix)
I have two small to medium sized files (2k) that are for all intents and purposes identical. The second file is the result of the first file being duplicated and replacing backslashes with forward slashes. The new file is bigger by 80 bytes (or one byte per line).
I did this with a simple batch script,and at first I thought the script might have unintentionally added some spaces or other artifacts. Or maybe the fact that their extensions are different has something to do with it (one has a tmp extension and the other has a lst extension).
From an editor, I replaced all forward slashes in the new file with backslashes and saved it without changing the extension.
And, hey guess what? The files were the same size again.
Now, before this is written off as a random fluke, I also see the same behavior exhibited in three other pairs of files (in other words six files) created in the same manner as the first. They are all one byte bigger per line in the file. The largest is about 12k bytes, and the smallest is about 2k.
I wouldn't think it has anything to do with escaping because I am on a Windows box using the Windows 7 cmd.exe shell.
Also one other thing. I tried the following:
echo \\\\\ >> a.txt
echo ///// >> b.txt
The files matched in size (7 bytes)
Does anyone have an explanation for this behavior?
I would suggest opening the files with an editor like Notepad++ that shows the type of linefeed (Windows/Mac/Unix). This is most likely your problem if the file size differs 1 byte per line.
Notepad++ can show line endings as small CR/LF symbols (View -> Show Symbol -> Show End of Line) and convert between the Windows/Mac/Unix line endings (Edit -> EOL Conversion).
Both Unix and Mac systems are usually storing files with an one byte line ending (Mac: CR, Unix: LF), Windows uses two bytes (CR LF).
Depending on the programs your batch scripts use, this might occur even though your system is a pure Windows box. The reason you don't get a difference when using an editor is that editors usually keep the file's original line endings.
Okay. I just solved it. #schnaader pointed me in the right direction. It actually has nothing to do with the forward or backslashes.
What happened is that my script added one character of trailing white space to each line. Why the file again became the same size after I reverted the slashes is because the editor I used to find and replace (Komodo Edit) is set up to automatically trim trailing white space on file save.
Funny.
I'm using the cake i18n command to extract the content of my __() functions in my application.
However, the default.pot output file is not encoded in UTF-8, and thus does not correctly display accentuated characters which is a problem since the main language is french (lot of 'é' , 'à' ...).
I'm using wamp server on Windows 7.
I've tried to change Windows console's encoding with chcp, to convert default.pot file in UTF-8 with notepad++ or PSpad editor, without success.
Do you know any way to get this default.pot file in UTF-8 ?
All the .php or .ctp files are edited with either Komodo or Geany, both on Windows and configured to use UTF-8.
Also i'm using subversion, if it helps.
Thank you for reading.
Had the same problem with cakephp 1.3 (not sure if it is fixed in 2.x): all "special" character which are not ANSI compliant (such as ä, ü, ö, ß), where extracted in the .pot file and there interpreted by ANSI (e.g. "ü" instead of "ü").
The solution mentioned by Camille (manually changing the characters) was not very feasable, since it was a lot of characters, this partly destroyed the .pot format and even worse an automated update of your .po file won't work.
The workaround I found was with the help of a comment in the php documentation for write() (which is used in the console task): http://www.php.net/manual/en/function.fwrite.php#73764.
According to the description there, I extended the file /cake/console/libs/tasks/extract.php with two lines:
First line went into the function __buildFiles():
$string = utf8_decode($string);
I wrote it in line 351, but it just needs to be in the second foreach loop and of couse before the variable is used by the function.
the second line went into the function __writeHeader():
replace the line $File->write($output); with
$File->write(utf8_encode($output));
That did it for me, take care the updating your cakephp will overwrite this changes.
I found a way to deal with this thanks to #Msalters. I changed the default encoding of my editor and overwrote wrong characters.