fix(python): echo what is typed at the >>> prompt

The REPL's move onto the blocking stdin syscall took it out from under the
only thing that had been showing a person their own keystrokes: the shell,
which echoes the characters it reads and hands a foreground child raw bytes
on purpose. Nothing below the guest cooks a terminal — process.stdin only
records setRawMode — so the reader of a line is what has to show it, and at
a >>> prompt that reader is repl().

makeLineReader takes an echo sink and becomes the line discipline while it
has one: each character as it arrives, DEL rubbing one out of the line as
well as off the screen, and a control byte shown as ^X so an arrow key's
ESC [ A cannot steer the cursor into output printed earlier.

Not in installStdin, one layer down, which would echo getpass() too with no
way for Python to stop it: Emscripten's tty reports ECHO already clear and
accepts a tcsetattr it ignores, so getpass prints no warning and the
password would be on the screen. input() therefore still shows nothing,
which is recorded as a known gap. Echo goes to stderr rather than stdout (an
echo is a write to the terminal, not part of what the process produces) and
only under VV_TTY=1, so captured and piped runs are unchanged.

Co-authored-by: Cursor <cursoragent@cursor.com>

Author: maitrungduc1410

AGENTS.md

@@ -2561,6 +2561,17 @@ Gotchas:
   `sys.exit(pytest.main(...))` on every run. Note Pyodide's WebLoop *also* re-raises
   SystemExit as a second, unhandled rejection — harmless in a browser, but Node aborts on
   it, so headless harnesses must swallow it.
+- **The interactive REPL is a second SystemExit path, and it echoes.** `exit()` typed at a
+  `>>>` comes back OUT of `code.InteractiveConsole.push` — CPython's `runcode` re-raises
+  `SystemExit` for the loop above it to act on — so `repl()` ends the session there, with
+  the code `terminationFromError` reads (it now names the ending: `exit`/`interrupt`/
+  `error`, so there is still one parser). A `KeyboardInterrupt` must NOT end it: name
+  printed, fresh top-level prompt. And the loop echoes what it reads, to **stderr** and only
+  under `VV_TTY=1`, because nothing below the guest cooks a terminal (see the shell/stdin
+  section). Do not move that echo into `installStdin`: it would cover `getpass()`, which
+  cannot turn it off — Emscripten's tty reports ECHO already clear and ignores `tcsetattr`,
+  so no warning is printed and the password is on the screen. `input()` echo is therefore
+  still missing, on purpose.
 - **Django works, but only on WSGI**, and only with `DJANGO_ALLOW_ASYNC_UNSAFE=1` and
   `tzdata`. Its ASGI path goes through `asgiref`, which starts a `ThreadPoolExecutor` per
   request even for `async def` views — the existing `anyio` patch does not help, that is a
@@ -3492,7 +3503,13 @@ runtime's `drainStdin` normalizes strings vs bytes to a Buffer). The host termin
 The interactive line editor (echo, backspace, Ctrl+C→SIGINT the whole foreground
 job — every stage of a pipeline via `currentKill`, with keystrokes forwarded to
 the pipeline's first stage) lives in the `sh` coreutil, not in a TTY line
-discipline — there's nothing cooked below it. It also does **↑/↓ history recall**
+discipline — there's nothing cooked below it. **The consequence for any other
+program that reads lines: whoever reads a line has to show it.** `sh` echoes only
+what *it* reads and forwards raw keystrokes to a foreground child on purpose, and
+`process.stdin.setRawMode` merely records the mode, so a child that reads and does
+not echo (which is what the Python REPL did) leaves the person typing blind. Echo
+belongs in that program's own read loop — see `repl()` in `builtins/python.js`,
+which echoes to stderr under `VV_TTY` for the reasons in the Python section. It also does **↑/↓ history recall**
 (a module-scoped `commandHistory` array shared with the `history` builtin, which
 lists it bash-style 1-indexed) and **Tab completion** (first token → builtins +
 PATH programs; later tokens → the VFS, dirs suffixed `/`; unique match inserts +
@@ -4196,6 +4213,26 @@ Two smaller ones from the same batch, both worth knowing before you touch these
   the change.** The blocking stdin syscall worked on the first try; what it broke was the REPL,
   which had been reading the flowing stream perfectly happily until an `input()` at a `>>>` prompt
   could take stdin away from it.
+- **Moving a reader moves it out from under whatever was quietly serving it.** The same move cost
+  the REPL its echo, and it took a user session to notice: nothing the person typed appeared, so
+  the only thing on screen was the output of the `print()` calls they were typing blind. Nothing
+  in this system echoes on a program's behalf — xterm does not, `process.stdin.setRawMode` only
+  records the mode, and `sh` echoes what *it* reads and forwards raw bytes to a foreground child
+  deliberately. Ask what the layer you are leaving was doing for you besides the thing you came
+  for.
+- **The layer that is easiest to echo from is the one that leaks the password.** Echoing inside
+  `installStdin` — the interpreter's own stdin callback — would have covered `input()` too, and
+  `getpass()` could not have switched it off: Emscripten's tty answers `tcgetattr` with ECHO
+  already clear and accepts a `tcsetattr` it ignores, so getpass prints none of its "cannot
+  control the terminal" warnings and reads the password onto the screen. Both facts were measured
+  against the real interpreter before the layer was chosen. Echo therefore sits in the REPL loop,
+  which knows its line is source meant to be seen, and `input()` echo stays an open gap.
+- **A `SystemExit` that CPython re-raises is a message to the loop above it.**
+  `code.InteractiveInterpreter.runcode` re-raises it instead of reporting it *because* the driving
+  loop is supposed to end the session; a `catch` that treats every exception as printable text
+  turns `exit()` into a traceback plus another prompt. When you find yourself parsing one, check
+  whether the file already has a parser — `terminationFromError` did, and now reports which of
+  `exit`/`interrupt`/`error` it found so the REPL can act without a second copy of the rules.
 - **A skip-list entry is a recorded reason, not a rule.** `python` was excluded from debug targets
   because instrumenting a Node shim debugs the shim. Deleting the entry to add Python debugging
   would have done exactly the thing the comment warned about — and done it silently, offering

ARCHITECTURE.md

@@ -1792,6 +1792,31 @@ flowing stream meant the first `input()` at a `>>>` prompt took stdin away from
 The cost is that the process's event loop does not turn while a prompt waits, which is what
 CPython does at a `>>>` as well.
 
+**The REPL also echoes, because in this system the reader of a line is what shows it.** There
+is no cooked-mode line discipline below the guest — `process.stdin.setRawMode` records the
+mode and nothing more, and `sh` echoes the keystrokes *it* reads while handing a foreground
+child raw bytes so the child can drive its own display. So `sh` echoes at its prompt and
+`repl()` echoes at a `>>>`, through the same `makeLineReader`, which with an echo sink also
+applies what a canonical terminal would: DEL leaves the character neither in the line nor on
+the screen, and a control byte is shown as `^X` (echo an arrow key's `ESC [ A` verbatim and it
+steers the terminal's cursor into output printed earlier). It writes to **stderr** — an echo
+goes to the terminal, not into this process's stdout, which may be a pipe — and only when
+`VV_TTY=1` says a terminal is attached, so captured and scripted runs are unchanged.
+Deliberately *not* in `installStdin`, one layer down: that is every read the interpreter makes,
+`getpass()` included, and Python cannot opt out here because Emscripten's tty reports ECHO
+already clear and accepts a `tcsetattr` it ignores — getpass would print no warning and the
+password would be on screen. The cost of that choice is that `input()` typed at a prompt still
+shows nothing.
+
+**`exit()` ends the session with its exit code.** `exit`/`quit`/`sys.exit` raise `SystemExit`,
+and `code.InteractiveInterpreter.runcode` re-raises it rather than reporting it, for the loop
+above to act on; the loop reads it with the same `terminationFromError` a script's top-level
+exception goes through (it names the ending — `exit`, `interrupt`, `error` — so the REPL needs
+no SystemExit parser of its own), so `exit()`/`exit(0)` leave 0, `exit(3)` leaves 3 and
+`exit("bye")` prints `bye` to stderr and leaves 1. Ctrl-D is a newline and 0. A
+`KeyboardInterrupt` is the one that must *not* end it: it prints its name and returns to a
+fresh top-level prompt, abandoning any half-typed block.
+
 **The first interpreter of a session is snapshotted, and the rest resume from it.** Booting
 CPython costs ~1.8s and this runtime pays it per command, which was the single biggest thing
 wrong with Python here. Pyodide can serialise a just-booted interpreter's linear memory and

packages/runtime/builtins/python.js

@@ -143,31 +143,37 @@ export function flushStreams(pyodide) {
 // integer, prints just that argument and exits 1. We used to dump the whole
 // WASM traceback for every sys.exit(), which meant a clean `sys.exit(0)` — what
 // `python -m pytest` does on every green run — looked like a crash.
+//
+// `kind` names WHICH of the three this was, because the interactive REPL has to
+// tell them apart and must not grow a second SystemExit parser to do it: an
+// `exit()` typed at a `>>>` ends the session with this code, a Ctrl-C returns to
+// a fresh prompt, and anything else is one statement's error in a session that
+// carries on. A script needs none of that distinction and ignores the field.
 export function terminationFromError(e) {
   const msg = (e && e.message) || String(e);
   const last = msg.trimEnd().split("\n").pop().trim();
   // Ctrl-C. CPython prints the traceback like any other exception and exits
   // 128+SIGINT, and a shell that reports 130 is how a script author tells an
   // interrupted run from a failed one.
   if ((e && e.type === "KeyboardInterrupt") || /^KeyboardInterrupt\b/.test(last)) {
-    return { code: 130, report: msg };
+    return { kind: "interrupt", code: 130, report: msg };
   }
   const isExit = (e && e.type === "SystemExit") || /^SystemExit\b/.test(last);
-  if (!isExit) return { code: 1, report: msg };
+  if (!isExit) return { kind: "error", code: 1, report: msg };
   const m = /^SystemExit:\s*([\s\S]*)$/.exec(last);
   const value = m ? m[1].trim() : "";
-  if (!value || value === "None") return { code: 0, report: "" }; // bare sys.exit()
-  if (/^-?\d+$/.test(value)) return { code: Number(value) | 0, report: "" };
+  if (!value || value === "None") return { kind: "exit", code: 0, report: "" }; // bare sys.exit()
+  if (/^-?\d+$/.test(value)) return { kind: "exit", code: Number(value) | 0, report: "" };
   // Bools ARE ints in Python: sys.exit(True) exits 1 and sys.exit(False) exits
   // 0, printing nothing either way. The traceback spells both as
   // "SystemExit: True"/"False" — indistinguishable from sys.exit("True"), so
   // the message is a lossy channel and this picks the far likelier reading.
   // `sys.exit(not ok)` is a common idiom; exiting with the literal string
   // "False" is not. It is also the reading that keeps a *successful* run
   // reporting success, which the string reading got backwards.
-  if (value === "True") return { code: 1, report: "" };
-  if (value === "False") return { code: 0, report: "" };
-  return { code: 1, report: value }; // sys.exit("message")
+  if (value === "True") return { kind: "exit", code: 1, report: "" };
+  if (value === "False") return { kind: "exit", code: 0, report: "" };
+  return { kind: "exit", code: 1, report: value }; // sys.exit("message")
 }
 
 // Undo one consequence of our own Node masquerade: it switches Python's HTTP off.
@@ -911,8 +917,13 @@ export function dataPackagesFor(source) {
  *
  * Returns null at end of input — but a part-typed line without its newline is
  * still a line, as it is in CPython when you type something and press Ctrl-D.
+ *
+ * With an `echo` sink this also becomes the line discipline a canonical-mode
+ * terminal would provide, because nothing under it does: it shows each character
+ * as it arrives and lets DEL rub one out. Only the interactive REPL passes one —
+ * see repl(), which also decides when echoing is right at all.
  */
-export function makeLineReader(read) {
+export function makeLineReader(read, echo) {
   const readChunk = read || (() => (globalThis.__ocReadStdin ? globalThis.__ocReadStdin() : null));
   let buf = "";
   return () => {
@@ -932,7 +943,33 @@ export function makeLineReader(read) {
         }
         return null;
       }
-      buf += chunk;
+      if (!echo) {
+        buf += chunk;
+        continue;
+      }
+      for (const ch of chunk) {
+        if (ch === "\x7f" || ch === "\b") {
+          // Erase within the line being typed only: a DEL at a fresh prompt must
+          // rub out neither the prompt that invited it nor a line already queued
+          // behind this one (a paste arrives as one chunk of several lines).
+          if (buf && !buf.endsWith("\n")) {
+            buf = buf.slice(0, -1);
+            echo("\b \b");
+          }
+          continue;
+        }
+        buf += ch;
+        // Control characters go on the screen as ^X, which is what a terminal
+        // with ECHOCTL does and is here for a sharper reason than fidelity: an
+        // arrow key arrives as the three bytes ESC [ A, and echoing those
+        // verbatim would move the terminal's cursor into output printed earlier
+        // and type the rest of the line there. Newline and tab are excluded
+        // because their effect on the screen is the point of them.
+        const code = ch.charCodeAt(0);
+        echo(code < 0x20 && ch !== "\n" && ch !== "\r" && ch !== "\t"
+          ? "^" + String.fromCharCode(code + 64)
+          : ch);
+      }
     }
   };
 }
@@ -2278,8 +2315,10 @@ json.dumps({
         const console_ = pyodide.globals.get("_vv_console");
 
         let more = false;
+        let ended = false;
         const prompt = () => process.stdout.write(more ? "... " : ">>> ");
         const finish = (codeVal) => {
+          ended = true;
           try {
             console_.destroy && console_.destroy();
           } catch {
@@ -2292,6 +2331,25 @@ json.dumps({
             // InteractiveConsole.push returns True when more input is needed.
             more = !!withInterruptsSync(() => console_.push(line));
           } catch (e) {
+            const t = terminationFromError(e);
+            // exit(), quit(), sys.exit(): CPython's InteractiveInterpreter.runcode
+            // re-raises SystemExit instead of reporting it (Lib/code.py) precisely
+            // so that the loop driving it can end the session — and this is that
+            // loop. Treated as a printable error, as it used to be, `exit()`
+            // answered with a traceback and a fresh prompt: a crash report for
+            // the one line every user of a REPL knows how to type.
+            //
+            // The code and the message are the same reading a script's top-level
+            // SystemExit gets, from the same parser: exit()/exit(0) leave 0,
+            // exit(3) leaves 3, exit("bye") prints bye and leaves 1.
+            if (t.kind === "exit") {
+              flushStreams(pyodide);
+              if (t.report) {
+                process.stderr.write(t.report.endsWith("\n") ? t.report : t.report + "\n");
+              }
+              finish(t.code);
+              return;
+            }
             // Ctrl-C during a statement. CPython prints the name alone and gives
             // a fresh top-level prompt, abandoning any half-typed block — the
             // session survives, which is the whole point of interrupting it.
@@ -2322,7 +2380,29 @@ json.dumps({
         //
         // The cost is that this process's event loop does not turn while the
         // prompt waits, which is what CPython does at a `>>>` too.
-        const readLine = makeLineReader();
+        //
+        // And it echoes, because in this system nobody else can. On a real
+        // terminal the keystroke a person types is shown by the line discipline
+        // in the kernel's tty layer, and there is none here: process.stdin
+        // records setRawMode and nothing more (packages/runtime/index.js), and
+        // the shell hands its foreground child raw keystrokes without echoing
+        // them (coreutils.js) exactly so the child can drive its own display.
+        // So the reader of a line is the thing that must show it, which is why
+        // the shell echoes at its own prompt and why this loop must at a `>>>`.
+        //
+        // Not one layer lower, in installStdin: that would echo every read the
+        // interpreter makes, including `getpass()`, and Python could not turn it
+        // off — Emscripten's tty answers tcgetattr with ECHO already clear and
+        // accepts a tcsetattr it then ignores, so getpass believes echo is off,
+        // prints no warning, and the password would go up on the screen.
+        //
+        // To stderr, not stdout, because echo is a write to the terminal and not
+        // part of what this process produces: `cat script.py | python > out` must
+        // not find the typed source in out. And only with a terminal attached
+        // (VV_TTY, the shell's own marker — the same one `ls` colours on), so a
+        // captured or scripted run stays byte-for-byte what it was.
+        const echo = process.env.VV_TTY === "1" ? (text) => process.stderr.write(text) : null;
+        const readLine = makeLineReader(null, echo);
 
         // One statement per macrotask rather than a `while` loop, so timers and
         // the process's own exit path get their turn between lines.
@@ -2334,6 +2414,9 @@ json.dumps({
             return;
           }
           feed(line);
+          // An `exit()` on that line ended the session. Reading again would park
+          // this process on a stdin nobody is going to type into.
+          if (ended) return;
           setTimeout(step, 0);
         };
         prompt();