coreutils icon indicating copy to clipboard operation
coreutils copied to clipboard

fail!() writes to stderr

Open mahkoh opened this issue 11 years ago • 6 comments

fail! writes an error message to stderr. Every function call that can fail is a potential rust error message to stderr. Consider the following code

~/rust/coreutils/build$ ./cat /etc/fstab | grep -L 
Usage: grep [OPTION]... PATTERN [FILE]...
Try 'grep --help' for more information.
task '<main>' failed at 'called `Result::unwrap()` on an `Err` value: broken pipe (Broken pipe)', /build/rust-git/src/rust/src/libcore/result.rs:548

This is not how cat should behave. There are currently 129 calls to unwrap() in coreutils.

There is currently no way to make fail! simply call abort which would probably be sufficient for coreutils. You can use stdio::set_stderr to set the writer used by fail!() or you can remove every call that can fail.

Note that println! will also call fail on sigpipe. There are currently 420 occurrences of println!.

mahkoh avatar Jul 30 '14 00:07 mahkoh

Not every call to unwrap() is at risk of failing. However, I agree that those that are should be fixed.

I added pipe_println! a little while ago to handle the SIGPIPE. It should probably not fail in the case of another error, though.

Arcterus avatar Jul 30 '14 20:07 Arcterus

Using set_stderr is the simpler solution. You only have to do this in mkmain.rs and src/uutils/uutils.rs. You can also use libc::?::signal to turn on sigpipe's default behavior.

mahkoh avatar Jul 30 '14 21:07 mahkoh

I don't think we want to ignore an occurrence of fail! that shouldn't occur (such as when there is a bug in the program). However, we do want to _prevent_ fail! from being called in the case of a normal error (e.g. incorrect arguments, issue opening a file, etc.).

I hadn't thought about using signal. That's probably the best solution for the SIGPIPE.

Arcterus avatar Aug 05 '14 03:08 Arcterus

I think this can be fixed by just adding panic = "abort" to all the Cargo.tomls now.

Arcterus avatar Jul 28 '17 11:07 Arcterus

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

stale[bot] avatar Mar 27 '21 11:03 stale[bot]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

stale[bot] avatar Jan 21 '23 13:01 stale[bot]