Skip to content

SIGPIPE panics #192

Open
Open

Description

@oech3

Using tag/latest-commit

diffutils diff /etc/pacman.conf /dev/null | :

thread 'main' (39158) panicked at src/diff.rs:94:41:
called `Result::unwrap()` on an `Err` value: Os { code: 32, kind: BrokenPipe, message: "Broken pipe" }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Activity

  1. GunterSchmidt commented on Mar 8, 2026

    @GunterSchmidt
    Contributor

    Yes, I have noticed this .unwrap() on io before.

    What is the desired behavior? Let this pass, because it is intentionally?

            if let Err(e) = io::stdout().write_all(&result) {
                // let broken pipe pass, report other errors
                if e.kind() != io::ErrorKind::BrokenPipe {
                    eprintln!("{e}");
                    return ExitCode::FAILURE;
                }
            }
    
    

    I am also working on an optimized error handling with enums to make it library friendly.

  2. GunterSchmidt commented on Mar 9, 2026

    @GunterSchmidt
    Contributor

    I researched your hint and found uutils/coreutils#9657, so I just copied that behavior and added PR #194. Could you please check that.

  3. oech3 commented on Mar 9, 2026

    @oech3
    ContributorAuthor

    It should be able to import uucore instead of copy and pasting.

  4. GunterSchmidt commented on Mar 9, 2026

    @GunterSchmidt
    Contributor

    Yes, that is what I did. I still needed to implement the imported functionality.

  5. GunterSchmidt commented on Mar 10, 2026

    @GunterSchmidt
    Contributor

    With my current implementation you will get

    >diffutils diff /etc/pacman.conf /dev/null | :
    diffutils: write error: Broken pipe
    
    

    GNU diff does suppress it completely.

    This could easily be changed, I would just need to add one line in diff.rs:

    pub fn main(opts: Peekable<ArgsOs>) -> ExitCode {
        uucore::panic::mute_sigpipe_panic();
    
    

    Would you prefer that? It would mimic GNU diff behavior, but has less information.

  6. oech3 commented on Mar 10, 2026

    @oech3
    ContributorAuthor

    I'm OK. But maintainer should determine how to fix this instead of me.

  7. GunterSchmidt commented on Mar 10, 2026

    @GunterSchmidt
    Contributor

    Fine, I strongly believe, it should stay as I fixed it.

  8. GunterSchmidt commented on Mar 12, 2026

    @GunterSchmidt
    Contributor

    As the issues were closely related I fixed #165 also in this PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions