Gofmt canonicalizes line endings?

Technical Discussion
1

Hi :slight_smile:

The following issue implies gofmt is supposed to enforce \n line endings (not \r\n), even on Windows.

But today I saw a report of many \r left behind!

The intent IS for gofmt to remove any \r at line endings… is that right?

2

The comments in the issue indeed indicate that the expected behavior of gofmt is to canonicalize all line endings to \n. Is the report you are referring to available somewhere?

1 Like
3

Thanks, that was my interpretation too.

Although it’s not a formal report, the thread is here:

4

Re-reading issue #2242 it occurs to me that there are different opinions/observations about how gofmt handles line endings. With the tweet conversation, it makes three:

  1. gofmt always changes line endings to \n, even on Windows.
  2. gofmt changes line endings to \n on Unix-like systems, and to \r\n on Windows.
  3. gofmt changes line endings to \n (on Unix only or on Windows, too??) but leaves line endings in comments alone. So if the file has Windows format, gofmt leaves line endings in comments as \r\n.

I have tested the behavior on Linux with go 1.7 by feeding a dos-formatted file to gofmt and found that all line endings, including those in comments, were changed to \n.

Here is the hex dump (look for 0d0a versus 0a):

$ hexdump -C gofmt.go 
00000000  2f 2f 20 61 20 6d 75 6c  74 69 2d 6c 69 6e 65 20  |// a multi-line |
00000010  63 6f 6d 6d 65 6e 74 0d  0a 2f 2f 20 73 65 63 6f  |comment..// seco|
00000020  6e 64 20 6c 69 6e 65 0d  0a 2f 2f 20 74 68 69 72  |nd line..// thir|
00000030  64 20 6c 69 6e 65 0d 0a  70 61 63 6b 61 67 65 20  |d line..package |
00000040  6d 61 69 6e 0d 0a 0d 0a  69 6d 70 6f 72 74 20 28  |main....import (|
00000050  0d 0a 22 66 6d 74 22 0d  0a 29 0d 0a 0d 0a 66 75  |.."fmt"..)....fu|
00000060  6e 63 20 6d 61 69 6e 28  29 20 7b 0d 0a 20 20 20  |nc main() {..   |
00000070  20 20 20 20 20 66 6d 74  2e 50 72 69 6e 74 6c 6e  |     fmt.Println|
00000080  28 22 57 65 6c 6c 2c 20  4f 68 2c 20 64 72 6f 6c  |("Well, Oh, drol|
00000090  22 29 0d 0a 7d 0d 0a 0d  0a                       |")..}....|
00000099
$ go fmt gofmt.go
gofmt.go
$ hexdump -C gofmt.go 
00000000  2f 2f 20 61 20 6d 75 6c  74 69 2d 6c 69 6e 65 20  |// a multi-line |
00000010  63 6f 6d 6d 65 6e 74 0a  2f 2f 20 73 65 63 6f 6e  |comment.// secon|
00000020  64 20 6c 69 6e 65 0a 2f  2f 20 74 68 69 72 64 20  |d line.// third |
00000030  6c 69 6e 65 0a 70 61 63  6b 61 67 65 20 6d 61 69  |line.package mai|
00000040  6e 0a 0a 69 6d 70 6f 72  74 20 28 0a 09 22 66 6d  |n..import (.."fm|
00000050  74 22 0a 29 0a 0a 66 75  6e 63 20 6d 61 69 6e 28  |t".)..func main(|
00000060  29 20 7b 0a 09 66 6d 74  2e 50 72 69 6e 74 6c 6e  |) {..fmt.Println|
00000070  28 22 57 65 6c 6c 2c 20  4f 68 2c 20 64 72 6f 6c  |("Well, Oh, drol|
00000080  22 29 0a 7d 0a                                    |").}.|
00000085
$

If someone can test this on Windows and observes a different behavior, it would definitely be a bug, according to rsc’s comments in the issue.

2 Likes
5

Hmm… thank you for checking :slight_smile:

I’ll relay this to the person having the problem. I suspect there’s a complication in his workflow!

6

Update:
“I use msys and bash and make and vim with native (non Cygwin) go on windows.”

Could running under bash on Windows have something to do with it?

I’m asking him to get some vars from go env … maybe there’s some confusion we can detect.

7

As this is a native Windows Go installation, testing go fmt in cmd.exe instead of in bash should reveal whether bash is involved.

8

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.