Strategy to handle added trailing carriage return during R-CMD-check on Windows

R-CMD-check fails on Windows due to a carriage return being added at the end of strings.

actual vs expected
171
- "X Y[![](D:/a/plume/plume/check/plume.Rcheck/plume/icons/orcid.svg){height=20px style='margin: 0 4px; vertical-align: baseline'}](https://orcid.org/0000-0000-0000-0000)\r"
172
+ "X Y[![](D:/a/plume/plume/check/plume.Rcheck/plume/icons/orcid.svg){height=20px style='margin: 0 4px; vertical-align: baseline'}](https://orcid.org/0000-0000-0000-0000)"

What's the recommended strategy to handle this?

I've found some mention of .gitattributes that might help here, but before diving more into this, I'd like to have some opinion from people with experience about this problem.

Edit:

It seems like I might also be able to control that with git config --global core.autocrlf. If so, would that be favored over using .gitattributes when not working in a team?

Possibly related, I have the following helper in my package to control how to rebuild the YAML header of .Rmd/.qmd files. Would using .gitattributes or git config also controls that for me automatically?

line_break <- function() {
  if (.Platform$OS.type == "unix") "\n" else "\r\n"
}

How are you writing out the contents to the file? Can you write it in a way that omits the \r characters?

2 Likes

I don't think I can do that (for what it's worth, here's the test). I could probably omit \r when extracting the string from the output file here with a better regex, e.g. (?<=## ).+(?=\\R)$. I can't test it on my machine though.

The function generating the link does it using a sprintf() template, which is then suffixed to author names via paste0().

Omitting \r every time I need to make these types of test doesn't seem very convenient though.

Instead of expect_equal(), would it help to use a regular expression instead, with expect_match()? As you said you could also edit md_extract_chunk_output(). You could do that in a git branch, open a PR and see if it works on the OS you don't have locally. Quite cheap. :slight_smile:

Or you could write your own custom expectation, that would remove the ending before testing the "equality".

Also note that expect_snapshot() has a handy transform argument.

Last idea, maybe you could skip pattern matching:

  • The HTML document you could parse with {xml2}.
  • The RTF document you could, hum, transform to HTML with {pandoc} then parse with {xml2} maybe. (now I agree that doesn't sound more straightforward :sweat_smile: )

That's weird, I made a test repo to experiment a bit but can't reproduce the problem.
I'll omit \r for now until I figure out what's going on. Thanks!

Then it is a heisenbug Heisenbug - Wikipedia :grin:

1 Like

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

If you have a query related to it or one of the replies, start a new topic and refer back with a link.