# By default read-line leaves the \\r character at the end of a line entered on the command line on Windows

**URL:** <https://racket.discourse.group/t/by-default-read-line-leaves-the-r-character-at-the-end-of-a-line-entered-on-the-command-line-on-windows/2235>\
**Category:** General\
**Created:** [August 21, 2023, 5:12pm UTC](https://racket.discourse.group/t/by-default-read-line-leaves-the-r-character-at-the-end-of-a-line-entered-on-the-command-line-on-windows/2235 "2023-08-21T17:12:37Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![spdegabrielle](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/spdegabrielle/32/95_2.png) [@spdegabrielle](https://racket.discourse.group/u/spdegabrielle)\
**Post date:** [August 21, 2023, 5:12pm UTC](https://racket.discourse.group/t/by-default-read-line-leaves-the-r-character-at-the-end-of-a-line-entered-on-the-command-line-on-windows/2235/1 "2023-08-21T17:12:37Z")

</div>

Topic for discussion of

> by default `read-line` leaves the `\r` character at the end of a line entered on the command line on Windows

Related GitHub items

- [https://github.com/racket/racket/pull/4074#issuecomment-1685861832](https://github.com/racket/racket/pull/4074#issuecomment-1685861832)
- [Suggest explicit mode of `'any` with `read-line`. · Issue #211 · jackfirth/resyntax · GitHub](https://github.com/jackfirth/resyntax/issues/211)

---

<div class="post-metadata">

**Author:** ![alexh](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/alexh/32/315_2.png) [@alexh](https://racket.discourse.group/u/alexh)\
**Post date:** [August 21, 2023, 1:24pm UTC](https://racket.discourse.group/t/by-default-read-line-leaves-the-r-character-at-the-end-of-a-line-entered-on-the-command-line-on-windows/2235/2 "2023-08-21T13:24:27Z")

</div>

I think the default for `read-line` is fine, and it is consistent with other languages.

I think the problem is that, in the Racket executable, `stdin` and `stdout` are opened in binary instead of text mode -- on Linux, this does not matter, but on Windows this causes the port to **not** translate the "\r\n" sequence into "\n".

A similar problem exists when writing. For example, on Window, when running the following program and redirecting the output to a file, produces a single "\n" in the file instead of the expected "\r\n":

```scheme
#lang racket
(write-string "Hello World\n")

```

The equivalent C++ program, when its output is redirected to a file, produces the expected "\r\n" at the end of the greeting:

```c++
#include <iostream>

int main()
{
    std::cout << "Hello World!\n";
    return 0;
}

```

The problem with the output line endings is less noticeable, since most windows utilities (including the famous notepad.exe) now handle files with "\n".

According to ([Text and Binary Mode File I/O | Microsoft Learn](https://learn.microsoft.com/en-us/cpp/c-runtime-library/text-and-binary-mode-file-i-o?view=msvc-170)), `stdin`, `stdout` and `stderr` are always opened in text mode by default, and the user needs to re-open them in binary mode if they want binary output (I don't think there is a Racket facility to change the text/binary mode of an open port)

Alex.

---

<div class="post-metadata">

**Author:** ![sorawee](https://avatars.discourse-cdn.com/v4/letter/s/ea5d25/32.png) [@sorawee](https://racket.discourse.group/u/sorawee)\
**Post date:** [August 21, 2023, 3:20pm UTC](https://racket.discourse.group/t/by-default-read-line-leaves-the-r-character-at-the-end-of-a-line-entered-on-the-command-line-on-windows/2235/3 "2023-08-21T15:20:09Z")

</div>

> I think the problem is that, in the Racket executable, `stdin` and `stdout` are opened in binary instead of text mode -- on Linux, this does not matter, but on Windows this causes the port to **not** translate the "\r\n" sequence into "\n".

I had the same thought, and @mflatt replied:

> (Changing `current-input-port` to be in text mode creates all sorts of other problems, because it depends on whether you wanted text input or binary input. We tried things like that in the early days.)

EDITED: added the missing response.

---

<div class="post-metadata">

**Author:** ![LiberalArtist](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/liberalartist/32/151_2.png) [@LiberalArtist](https://racket.discourse.group/u/LiberalArtist)\
**Post date:** [August 30, 2023, 5:14am UTC](https://racket.discourse.group/t/by-default-read-line-leaves-the-r-character-at-the-end-of-a-line-entered-on-the-command-line-on-windows/2235/4 "2023-08-30T05:14:41Z")

</div>

> [@sorawee](#):
>
> I had the same thought, and @mflatt replied:
> 
> > (Changing `current-input-port` to be in text mode creates all sorts of other problems, because it depends on whether you wanted text input or binary input. We tried things like that in the early days.)
> 
> EDITED: added the missing response.

A ghost of this lives on in `racket --help`:

```scheme
  -b, --binary
     No effect, since stdin and stdout/stderr are
     always binary

```

> [@alexh](#):
>
> I don't think there is a Racket facility to change the text/binary mode of an open port

A related but more limited feature I've sometimes wanted is a function somewhat like [`reincode-input-port`](https://docs.racket-lang.org/reference/port-lib.html#%28def._%28%28lib._racket%2Fport..rkt%29._reencode-input-port%29%29) that consumes one port and produces another, but performs precisely the same transformation on all platforms that text mode does on Windows. There are various functions that transform a broader class of newline encodings to `#\newline`, but I don't know a way to access exactly the same transformation that's built in on Windows.