Layout/EndOfLine detects Carriage Return in first line when BOM is not set in UTF-8

[marchwia]

Layout/EndOfLine detects CRLF in the first line of UTF-8 LF formatted files if BOM is not set.

Problem goes away after setting BOM.

---

Expected behavior

Pass with no errors for UTF-8 file without BOM.

Actual behavior

> rubocop test.rb
Inspecting 1 file
C

Offenses:

test.rb:1:1: C: Carriage return character detected.
#!/usr/bin/env ruby ...
^^^^^^^^^^^^^^^^^^^

Steps to reproduce the problem

test.rb

#!/usr/bin/env ruby
#

.rubocop.yml

Layout/EndOfLine:
  EnforcedStyle: lf

Command line

rubocop test.rb

RuboCop version

> rubocop -V
0.49.1 (using Parser 2.4.0.0, running on ruby 2.3.3 x64-mingw32)

[jonas054]

Are you absolutely sure there are no carriage return characters in the file when RuboCop reports Carriage return character detected.? Please check with od -a <file.rb> and see if there aren't any cr characters in there.

[marchwia]

No cr characters for sure:

> od -a test.rb
0000000   #   !   /   u   s   r   /   b   i   n   /   e   n   v  sp   r
0000020   u   b   y  nl   #  nl
0000026

[jonas054]

Well I'll be darned. Then I don't know. I haven't been able to reproduced the problem, and I've tried on a MinGW system.

If you could write a failing spec example, that would be perfect.

[a-nickol]

I have similar issues. Depending on the platform I use: windows commandline, mingw, or msys, I am getting different results.

Note that if rubocop is running in windows commandline rubocop -V it returns 0.52.1 (using Parser 2.4.0.2, running on ruby 2.4.1 i386-mingw32), too. Maybee marchwia has been using the native windows commandline, too.

The problems start to multiply when using guard-rubocop. Files which are clean when running rubocop alone, get offenses when scanned by guard-rubocop

[a-nickol]

I have no idea ...

https://gist.github.com/HansPeterIngo/aae6e1cb95b584ec9a70c93b72e9e416

[a-nickol]

If have done some more testing. I don't understand how the parameter --force-exclusion could change the results.

https://gist.github.com/HansPeterIngo/8fb359ba8cbec21e220cf7bfa2bfb6d2

[jonas054]

I have an idea what might be going on here. It's related to caching. It looks like a file whose line endings have changed still has the same hash key (used when caching the inspection result) as it had before the change. This is a bug in the caching mechanism. You should be able to work around it by running

rubocop --cache false

[a-nickol]

You are correct, after adding --cache false all commands return the correct result.

[jonas054]

I'll try to fix it.

[ChintuKarthi]

Are you absolutely sure there are no carriage return characters in the file when RuboCop reports Carriage return character detected.? Please check with od -a <file.rb> and see if there aren't any cr characters in there.

Hi, @jonas054 I have a cr in my file, can you explain how to solve this?

Thanks.

[jonas054]

Unfortunately, the Layout/EndOfLine cop doesn't support --auto-correct so RuboCop can't help you with this.

The solution depends on which platform you're running on (Mac, Windows, ...) and which IDE/Editor. In Emacs, for example, you can search and replace ^M. If you're on MacOS, see this answer: https://stackoverflow.com/questions/21621722/removing-carriage-return-on-mac-os-x-using-sed