read_all_text
result = read_all_text(path)
Input: path · Output: result
What it is
Reads path (string) in full.
Overloads
One call shape — this function is not overloaded.
| Code | Input | Output | Description |
result = read_all_text(path) | path stringnot documented yet | result string | Returns the whole file's content as one string. For splitting it into lines, open a handle with fopen and loop over read_line; for a file that isn't text, read it as raw bytes instead — read_bin(f, n) on a handle opened in binary mode, or read_array/mmap_read for typed/binary data. |
Examples
From the documentation, and run by the build -- the output and the figure below are what the engine actually produced. Simplest first.
txt = read_all_text(path)
print("chars: {len(txt)}")
from agent-guide
path = "/tmp/qu_scratch_append.txt"
write_text(path, "first line\n")
append_text(path, "second line\n")
print(read_all_text(path)) # "first line\nsecond line\n"
from collections-strings
n = fopen("notes.txt", "w")
write_line(n, "line one")
write_line(n, "line two")
close(n)
print(read_all_text("notes.txt"))
# line one
# line two
line one line two
from file-io
figure()
polygon([0.0, 1.0, 1.0], [0.0, 0.0, 1.0], fill = "#ff0000")
savefig(tmp_svg)
print(contains(read_all_text(tmp_svg), "opacity=\"0.18\"")) # true
from agent-guide
How it works
read_all_text(path) (§ wait until / sleep, scoped 2026-08-26) — a one-shot convenience for the single most common file-I/O idiom, "read this whole text file into a string": exactly read_all(fopen(path, "r")), just without needing a two-call, explicit-handle dance for a case that never needed one (a text-mode fopen reads the whole file into memory immediately — see its own doc comment — and there is no lingering OS handle to close() either way). Implemented directly against std::fs::read + from_utf8_lossy (the exact same two steps fopen("r") and text-mode read_all each perform) rather than literally constructing and discarding a Value::File, so this has no behavior gap from the two-call form — same bytes read, same lossy UTF-8 decoding, same "could not read" error wording — just fewer moving parts for a case with nothing to configure (no mode, no binary option: text is the whole point).
From the note above this builtin in the interpreter, where the reasoning was written down as it was built.