Infinite memory allocation when `print` runs inside a streaming closure with a zero-width terminal

Bug report form

• I have done a basic search of the issue tracker to find any existing issues that are similar.
• I have checked that my version is at least the latest stable release available via my installation method.

Describe the bug

I ran into this while writing a nushell script with the pi agent: it unexpectedly allocated a huge amount of memory and froze the machine

When nushell's stdout is a tty (pty) with a window size of 0 columns, calling print inside a streaming pipeline (e.g. ... | lines | each {|l| print $l }) leads to unbounded memory allocation: RSS grows at roughly 1 GB/s, CPU usage sits near 100%, and the process keeps running until it is killed by the OOM killer.

The problem disappears completely if the same pty is given a normal window size (stty cols 100), or if nushell's stdout is not a tty.

Notes

• The COLUMNS environment variable does not avoid the problem; nushell appears to read only the tty's TIOCGWINSZ.
• Indirect evidence: removing print from the closure and just returning the element (each {|l| $l }) causes no memory growth, but prints Couldn't fit table into 0 columns!, which shows nushell really did see a width of 0.
• Calling print only once (not inside a streaming closure) does not trigger it.
• It looks related to print's rendering/wrapping logic when the terminal width is 0, but I did not dig into the source.

How to reproduce

Key condition: nushell's stdout must be a 0-column pty. script(1) only fails to obtain a window size — and therefore only creates a 0x0 pty — when its own stdin is not a tty. So < /dev/null is required; without it, script inherits the size from the current terminal and the issue does not reproduce:

script -qec "nu --no-config-file -c '1..3 | each {|i| print \$i }'" /dev/null < /dev/null | cat

The command above does not depend on any external program. What I actually ran into was the same pattern applied to the output of an external command:

script -qec "nu --no-config-file -c '^bash -c \"echo a\" | lines | each {|l| print \$l }'" /dev/null < /dev/null | cat

Running the first command in a real terminal (stty size = 23 115), nu's RSS still grew to 3047 MiB and it had to be terminated.

Observation: the nu process's RSS grows by roughly 1 GB per second, CPU sits near 100%, and it never exits — until it is killed by the OOM killer. The amount of data print produces is tiny, yet the process keeps allocating.

Expected behavior

With a zero-width terminal, print should just print normally (or at least error out, or fall back to some default width) instead of allocating memory without bound.

Configuration