Printing anything prevents reading from stdin

[tad-lispy]

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

It's not possible to write to stdout or stderr and then process input line by line. Consider the following:

def main [] {
    print --stderr "Interpreter listening..."
    lines | each { str reverse | print }    
    print --stderr "Interpreter done."
}

The idea to use lines like this comes from #14901. I've also tried using input in a loop, but I can't figure out how to terminate it on EOF.

How to reproduce

Save the above script as sample.nu. Then run it:

$ nu --stdin sample.nu
Interpreter listening...
Interpreter done.

It exits without waiting for the input. Then comment out the first print statement, run it again and see it working correctly.

Expected behavior

The script should print to stderr, then wait for input. Each input line should be immediately printed in reverse. Pressing ctrl-d (or closing the input stream piped from another process) should result in the closing message being printed. After that the script should terminate without any error.

Configuration

key	value
version	0.111.0
major	0
minor	111
patch	0
branch
commit_hash
build_os	linux-x86_64
build_target	x86_64-unknown-linux-gnu
rust_version	rustc 1.94.0 (4a4ef493e 2026-03-02) (built from a source tarball)
cargo_version	cargo 1.94.0 (85eff7c80 2026-01-15)
build_time	1980-01-01 00:00:00 +00:00
build_rust_channel	release
allocator	standard
features	default, mcp, network, plugin, rustls-tls, sqlite, trash-support
installed_plugins
experimental_options	example=false, reorder-cell-paths=true, pipefail=true, enforce-runtime-annotations=false, native-clip=false

[fdncred]

What happens on 0.112.1?

[tad-lispy]

@fdncred same.

[Juhan280]

Its because print is the first command, so it gets the input stream.

def main [] {
    tee { print --stderr "Interpreter listening..." }
    | lines | each { str reverse | print }    
    print --stderr "Interpreter done."
}

[tad-lispy]

Thanks @Juhan280! It makes sense once you explained it to me, and I think I can work from here, but IMO this behavior is very unintuitive. Is it described somewhere? I spent at least an hour researching the issue before posting, and I was convinced I'm observing a bug in Nushell.

Should I try to contribute some docs? I guess it could go here: https://www.nushell.sh/lang-guide/chapters/pipelines.html#best-practices-for-pipeline-commands.

One thing I still don't get is why the original program proceeds. If as you say print takes the input, then shouldn't it await EOF before continuing to the next command? If it would, then lines should produce an error, as the input stream is already closed by the time the lines command is executed.

[Juhan280]

Thanks @Juhan280! It makes sense once you explained it to me, and I think I can work from here, but IMO this behavior is very unintuitive. Is it described somewhere? I spent at least an hour researching the issue before posting, and I was convinced I'm observing a bug in Nushell.

Should I try to contribute some docs? I guess it could go here: https://www.nushell.sh/lang-guide/chapters/pipelines.html#best-practices-for-pipeline-commands.

I don't know anything about that. Sorry

One thing I still don't get is why the original program proceeds. If as you say print takes the input, then shouldn't it await EOF before continuing to the next command? If it would, then lines should produce an error, as the input stream is already closed by the time the lines command is executed.

print didn't wait for EOF because you provided a positional argument to it.
lines gets a empty stream, and so it doesn't error out.
Try running just lines alone in the repl, it will just return nothing

[Juhan280]

Also an update the original snippet i shared:

def main [] {
    do {} (print --stderr "Interpreter listening...")
    | lines | each { str reverse | print }
    print --stderr "Interpreter done."
}

I replaced tee with do as tee clones the stream and is unpredictable.

The first argument of do is a closure which is empty which just passes the stream without modifying, and rest of the parameters are passed as the arguments to the closure. And since it runs before the closure, we abuse this to run this code.

Credit: Bahex

[tad-lispy]

@Juhan280

we abuse this to run this code.

Yeah, that captures my feeling pretty well. It feels like a big abuse of unrelated features 😅 And it's pretty fundamental stuff - reading from a stream and processing data as we do.

print didn't wait for EOF because you provided a positional argument to it.

So maybe it shouldn't "consume" it and the stream should be passed to the first command that actually "wants" input? That's what I was expecting. I think even better would be an explicit form like this:

print "About to read and process data from $in"
$in | lines | each { str reverse | print }
print "This happens after the $in stream is consumed. Bye bye!"

But I'm not experienced enough to be sure about it. Anyway, despite knowing a workaround (or two), and not knowing for certain what a good solution would be, I'd argue that the issue is real. So I don't want to close it. Do you agree?