Deno panic after pipe output to unknown command

[silverbucket]

Version: Deno 1.45.5 Platform: Max OS X 14.6.1

I accidentally typo'd in the command I wanted to pipe the output of coverage to. This generated a panic by Deno.

$ deno task coverage
Task coverage deno coverage | dun run mod.ts
dun: command not found

============================================================
Deno has panicked. This is a bug in Deno. Please report this
at https://github.com/denoland/deno/issues/new.
If you can reliably reproduce this panic, include the
reproduction steps and re-run with the RUST_BACKTRACE=1 env
var set and include the backtrace in your report.

Platform: macos aarch64
Version: 1.45.5
Args: ["/opt/homebrew/bin/deno", "coverage"]

thread 'main' panicked at library/std/src/io/stdio.rs:1118:9:
failed printing to stdout: Broken pipe (os error 32)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

[marvinhagemeister]

Does the error occur in the latest Deno version as well? I recall there being a fix for that a while back. You can upgrade to the latest Deno version by running deno upgrade.

[yazan-abdalrahman]

@silverbucket It's not reproducible with the last version.

[yazan-abdalrahman]

@silverbucket It's not reproducible with the last version.

@silverbucket @marvinhagemeister

Tell me how to correctly reproduce that.

[marvinhagemeister]

Nvm, I can reliably reproduce it in the latest version too. These are the reproduction steps:

1. Run deno init
2. Run deno test --coverage
3. Run deno coverage | echo "foo" -> Panic

Past related issue for deno -h https://github.com/denoland/deno/issues/22863

[yazan-abdalrahman]

but I thought issue on

$ deno task coverage

so I should add task with name coverage and this task do 'deno coverage | dun run mod.ts' and I tried that, and I run it task and everything works no panic

and I tried ur steps and also, I didn't faced panic

[marvinhagemeister]

Check the original issue description. Whenever you call deno task, deno prints out the resolved commands that will be run. That part is shown in the opening comment.

Looking at your screenshot it looks like you're running into a different error unrelated to the one described in this issue. The test command already fails, which it shouldn't and the coverage command bails out as well.

[yazan-abdalrahman]

@marvinhagemeister

Hi, the issue we can't use println! statement inside the BrokenPipe so I can't find solution nether than use an Alternative Output Channel like use eprintln! instead of println!to write the error message to stderr. This stream is usually not affected by a broken pipe in stdout. or use logging, Or we can ignore the BrokenPipe error entirely or print error message the The pipe is being closed.

[yazan-abdalrahman]

Hi, the issue we can't use println! statement inside the BrokenPipe so I can't find solution nether than use an Alternative Output Channel like use eprintln! instead of println!to write the error message to stderr. This stream is usually not affected by a broken pipe in stdout. or use logging, Or we can ignore the BrokenPipe error entirely or print error message the The pipe is being closed.

@marvinhagemeister @bartlomieju @dsherret

I have a workaround in the form of a custom println to handle errors. I will handle BrokenPipe problems by using another channel to print arag, and for other errors, I will output them as is.

is that acceptable?