Re: Print Behavior with Carriage Return

Oh duh! haha Thanks everyone for your responses. It makes total sense that the \r put the cursor back to the start of the line and then the value overwrote the key. I should have thought that one through a little longer before posting :)

Comment on Re: Print Behavior with Carriage Return

Replies are listed 'Best First'.
Re^2: Print Behavior with Carriage Return by haukex (Archbishop) on Jan 05, 2020 at 19:41 UTC
I should have thought that one through a little longer before posting :) No worries, you asked a well-formed question, and answering those is what we're here for `:-)` Since it hasn't been linked to yet: Basic debugging checklist	[reply] [d/l]
Re^2: Print Behavior with Carriage Return by BillKSmith (Monsignor) on Jan 05, 2020 at 23:05 UTC
Did you realize that with the johngg/haukex suggestion, your issue does not need an explanation or solution. It never arises. However, this is only a good idea if your open statement opens only windows files. Bill	[reply]
Re^3: Print Behavior with Carriage Return by haukex (Archbishop) on Jan 05, 2020 at 23:36 UTC
However, this is only a good idea if your open statement opens only windows files. Why do you say this? The `:crlf` layer doesn't hurt when opening files that have LF only. The following test passes on both Linux and Windows. Read more... (2 kB)	[reply] [d/l] [select]
Re^4: Print Behavior with Carriage Return by BillKSmith (Monsignor) on Jan 06, 2020 at 04:55 UTC
Yes, :crlf processes unix style files correctly, but for the wrong reason. (It does not translate Unix record separators, it fails to recognize them at all. This works because the Unix record separator and the perl newline are the same character.) I find this misleading, and recommend against it. Bill	[reply]
Re^5: Print Behavior with Carriage Return by haukex (Archbishop) on Jan 06, 2020 at 10:53 UTC