What is the difference between `r`n and `n for line breaks in Powershell?

Question

I know that there are different line-break codes in windows and unix. But in Powershell, both `r`n and `n work for a line break. Is there an automatic conversion from `n to `r`n and why do you have to use quotes instead of backslashes?

Answer 1

• On input, PowerShell accepts `r`n (Windows-style) and `n (Unix-style) and newlines interchangeably, irrespective of the platform (OS) it runs on; this applies both to reading PowerShell source-code files (such as *.ps1 scripts) and to all built-in cmdlets that read text, notably Get-Content.

  • `n is LF, the LINE FEED, U+000A character, used by itself as a newline on Unix-like platforms.

  • `r`n is CRLF, the newline sequence composed of a CARRIAGE RETURN (U+000D) character immediately followed by an LF, used as a newline on Windows.

  • ` is used above, because it is `, the backtick (formally known as GRAVE ACCENT, U+0060) that serves as the escape character in PowerShell, unlike in many other languages, where it is \ (for instance, `n in PowerShell corresponds to \n in C# and JavaScript, and `r`n to \r\n.

    • ` serves as the escape character in PowerShell:

      • inside expandable strings ("..."; but not inside '...', whose content is used verbatim) no
      • in unquoted arguments passed to commands, where its primary purpose is to escape metacharacters (characters such as ; that have syntactic function), i.e. to use them verbatim; e.g., Write-Host a`;b)
      • See the conceptual about_Special_Characters help topic for more information and the list of supported escape sequences.

    • Note that in regex contexts (such as via the -match and -replace operators), \-based escape sequences (such as \n) can still come into play, namely when these escape sequences are interpreted by the .NET regular-expression engine rather than by PowerShell itself (e.g. "a`nb" -replace '\n' yields 'ab'); see the conceptual about_Regular_Expressions help topic.

• On output, PowerShell uses the platform-native newline sequence: `r`n on Windows, `n on Unix-like platforms.

  • This applies to use of text-file-creating cmdlets, which comprise:

    • Cmdlets for plain-text file creation: Set-Content and Out-File / redirection operator >.
    • Cmdlets that create structured text files, such as Export-Csv.

  • As an aside:

    • In PowerShell [Core] 6+, the consistently used character encoding when text files are created (and read) is UTF-8 without a BOM.

    • By contrast, in Windows PowerShell (PowerShell versions up to 5.1), the default encodings vary by cmdlet, and choosing UTF-8 via the -Encoding parameter of an output cmdlet invariably creates a file with a BOM.

    • For more information about (default) character encodings in Windows PowerShell vs. PowerShell [Core], see this answer.

---

As for your specific questions:

Is there an automatic conversion from `n to `r`n?

In a sense, yes:

Saving to a file with a text-file-creating cmdlet implicitly uses the platform-native newline sequence, as discussed above.

Therefore, reading a file with Get-Content (which reads the file line by line by default) and saving these lines back to a file with Set-Content will effectively result in conversion of the original newlines to the platform-native newlines, if the original ones are from the respective other world.

Note that, separately, the character encoding may change, because once strings are read into memory, information about the input file's character encoding is lost, and text-file-creating cmdlets such as Set-Content apply their default encoding on output - see this answer for background information.

A targeted conversion to a specific newline style, irrespective of what platform you're running on, requires more work.

• See this answer.

why do you have to use backticks (`) instead of backslashes (\)?

\ as the escape character would have been a poor choice for PowerShell, because \ is used in file paths, given that \ serves as the (primary) file-system path separator on Windows, and given that passing file paths as arguments is a very common use case in shells.

Having to \-escape these path separators to disambiguate them from \ as the escape character (e.g, "C:\\Program Files\\PowerShell" instead of "C:\Program Files\PowerShell") would have been an undue burden (this escaping is annoying enough in programming languages such as C# and JavaScript, though recent versions now offer alternative syntax forms where the escaping isn't needed).

Therefore, PowerShell needed a different escape character, and settled on `, because:

• it is rare in literal use; that is, you'll rarely have to escape ` itself - as `` - in order to use it verbatim.

• at least on English keyboards, it is easy to type.

Other shells:

• cmd.exe too had to choose a different escape character, and chose ^, the caret (formally known as CIRCUMFLEX ACCENT, U+005E).

• POSIX-like shells such as Bash never faced this problem, because it is /, not \, that serves as the separator in Unix file-system paths; therefore, these shells use \ as the escape character, like most programming languages.

Answer 2

If you're talking scripts, PowerShell will interpret both the \n and \r\n end-of-line (EOL) sequence equally when parsing. The \r\n EOL is mostly a Windows artifact of the past, and most of the modern (ca. 2018) Windows apps released will interpret them the same.

Those are not quotes, but grave accents or backticks (the tilde key on most keyboards) and they are the designated string escape character in PowerShell.

One thing that does impact parsing of a Windows PowerShell script is the use of a Byte Order Mark (BOM). This is the only way to get the PowerShell interpreter to see unicode (such as emojis) in your code; that is, by using UTF8-BOM.

Answer 3

When the file is read into an array of strings with get-content (without -raw), there's no line endings at all. Then out-file (">") or set-content will put the line endings in depending on the operating system. Mac OS used to be `r only, but it's just like unix now, `n.

Here's a file in osx with just `n (0x0A):

format-hex file


   Label: /Users/js/foo/file

          Offset Bytes                                           Ascii
                 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
          ------ ----------------------------------------------- -----
0000000000000000 61 62 63 0A 61 62 63 0A                         abc�abc�

I have a post about converting formats over here: Unix newlines to windows newlines (on Windows)