`more` crashes when attempting more lines than terminal lines

[hbina]

Running something like:

for i in {1..100..1}; do echo "$i"; done | cargo run -- more

or

cat Cargo.toml Cargo.lock | cargo run -- more

Will just crash with

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: IoError(Custom { kind: Other, error: "Failed to initialize input reader" })', src/uu/more/src/more.rs:235:51

[tertsdiepraam]

Hi! Thanks for putting this in its own issue! Could you provide some more information about your setup, like OS, shell, etc?

[ycd]

I am able to reproduce too:
OS: MacOS
Shell: Zsh
Terminal: Alacritty

42
43
44
--More--(44%)thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: IoError(Custom { kind: Other, error: "Failed to initialize input reader" })', src/uu/more/src/more.rs:239:12
                               note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

The interesting part is if i change my shell, more doesn't works

Output in bash:

bash-3.2$ for i in {1..100..1}; do echo "$i"; done | cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.08s
     Running `/Users/yagizcandegirmenci/workspace/opensource/coreutils/target/debug/more`

Output in fish:

yagizcandegirmenci@Yagzs-MacBook-Pro ~/w/o/c/s/u/more (refactor-chroot)> echo araba | cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.09s
     Running `/Users/yagizcandegirmenci/workspace/opensource/coreutils/target/debug/more`

CC: @arijit79

[tertsdiepraam]

Is it only happening when reading from stdin?

[hbina]

It seems to be an issue with crossterm. It's enough to crash the example in crossterm with this:

 cat Cargo.toml | cargo run --example event-poll-read

tested on MacOS.

[AMythicDev]

I think this issue occurs only on MacOS. Unfortunately I don't own a Mac so I can't test it and report it back to the crossterm guys.

Could someone create an issue on their GH repo

[AMythicDev]

Could someone please give me a backtrace of the error and whether it only happens when reading from stdin or does it also happen when reading from a file directly.

[gingk1212]

I was able to reproduce this as well.

• OS: macOS Big Sur
• Shell: Bash
• revision: 746e35c

please give me a backtrace of the error

$ for i in {1..100}; do echo $i; done | RUST_BACKTRACE=1 cargo run -- more
    Finished dev [unoptimized + debuginfo] target(s) in 0.59s
     Running `target/debug/coreutils more`
1
2
...
38
39
--More--(39%)thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Custom { kind: Other, error: "Failed to initialize input reader" }', src/uu/more/src/more.rs:229:51
stack backtrace:
    0: rust_begin_unwind
        at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/std/src/panicking.rs:498:5
    1: core::panicking::panic_fmt
        at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/core/src/panicking.rs:116:14
    2: core::result::unwrap_failed
        at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/core/src/result.rs:1690:5
    3: core::result::Result<T,E>::unwrap
        at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/core/src/result.rs:1018:23
    4: uu_more::more
        at ./src/uu/more/src/more.rs:229:12
    5: uu_more::uumain::uumain
        at ./src/uu/more/src/more.rs:91:9
    6: uu_more::uumain
        at ./src/uu/more/src/more.rs:52:1
    7: coreutils::main
        at ./src/bin/coreutils.rs:95:31
    8: core::ops::function::FnOnce::call_once
        at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/core/src/ops/function.rs:227:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

whether it only happens when reading from stdin or does it also happen when reading from a file directly.

It seems to be the former. cat Cargo.toml | cargo run -- more crashes, but cargo run -- more Cargo.toml doesn't.

If you have anything else you would like to check, please let me know.

[tertsdiepraam]

Thank you for the stack trace! Based on the line numbers in that stack trace it's this line where the unwrap panics:

if event::poll(Duration::from_millis(10)).unwrap() {
    // ...
}

I'm not sure there is much we can do here, except maybe report this to crossterm? We should however handle this case more elegantly, but that will not fix the issue, just make the error prettier :)

@gingk1212 Could you test this with the latest crossterm:

cat Cargo.toml | cargo run --example event-poll-read

and if that still fails on the latest crossterm open an issue there with the stack trace? If they fixed this issue in the meantime, then we'll just have to wait until we can upgrade to that version.

[tertsdiepraam]

Ah, it looks like there is already an issue on crossterm: crossterm-rs/crossterm#396

[apatrushev]

I investigated a lot of info around this issue in crossterm based projects and it looks like use-dev-tty feature can fix the issue. I tried it on my MacOS and panic disappears. I will create PR with the fix.