rg --help | less assumes the terminal has 100 columns

[bluss]

If we pipe rg's output to something, it assumes the terminal has 100 columns.

For example rg --help, which has output that is long and begs for pagination.

To reproduce: Install rg. Adjust terminal to a width of for example 90 columns. Use rg --help | less (with no shell aliases or anything in between).

(Sorry! rg --help is now fixed, so the bug report now had its schedule unblocked)

[BurntSushi]

ripgrep doesn't do anything explicitly smart with terminal size, so I assume this is a clap thing.

[BurntSushi]

I could have sworn clap had some setting or knob for this, but I can't find it after a quick skim.

[kbknapp]

There's App::max_term_width and App::set_term_width

max_term_width will allow freeform "smart" wrapping at whatever the user terminal width is, up to some maximum. This is what ripgrep uses currently (at 100).

set_term_width sets the virtual width and always "smart" wraps at that column width.

[kbknapp]

[I hit comment too early]

Not using either will just "smart" wrap at whatever width the user terminal width happens to be.

[BurntSushi]

@kbknapp Oh interesting. Welp. I was clearly wrong about ripgrep not doing anything.

With that said, I can't seem to cause clap to do the right thing here. Namely, if max_term_width is set to 100, then shouldn't it wrap text at N < 100 after I shrink my terminal? (I also just tried set_term_width, which has the same behavior.)

If I remove the max_term_width/set_term_width setting completely, then the help text sprawls across my entire screen, which I suspect is why I set it in the first place.

[BurntSushi]

I see. clap does do the right thing unless its output is piped to less. So presumably that interferes with clap figuring out the terminal width?

[kbknapp]

Interesting, my initial thinking is less is being detected a terminal without a width (or rather stdout not being a terminal) which is causing the fallback to 100.

[BurntSushi]

I haven't looked at clap's source code, but my best guess is that clap only does autowrapping when it thinks its printing to a tty (which seems reasonable). So if its output is piped to a file or to another program, then it won't auto-wrap because it isn't a tty. It should be possible to discriminate between "redirected to a file" and "piped to other process," but even then, it's not clear that respecting terminal size is the right choice (although it certainly seems like a pragmatic one).

Another choice is to just set the max width to 79 columns and hope that fits most use cases.

[BurntSushi]

@kbknapp Ah right, beat me to it!

[kbknapp]

Here's where the logic happens

https://github.com/kbknapp/term_size-rs/blob/0297b6af8a6072ef1bee30527b6cb39f55b44755/src/lib.rs#L58-L82

[BurntSushi]

@kbknapp Oh, I suppose that is actually a different issue than what I was saying above. That's suggesting that ioctl itself will fail to find the terminal size if the process is being piped to another process? Or rather, finding the dimensions works by examining the stdout file descriptor? Interesting.

[kbknapp]

@BurntSushi ioctl will fail when stdout isn't a tty. The crux of the problem is that the dimensions are determined by stdout, and where stdout is piped or redirected there are no dimensions. I don't know of a way to detect what the terminal width was (i.e. before stdout is checked).

[kbknapp]

@BurntSushi I found a solution that seems to work! 🎉

term_size can read stdout, and if that fails try stdin...if that fails then try stderr...then give up. Works in my tests so far.

[BurntSushi]

Nice hack. I love it.

…

On Apr 9, 2017 1:46 PM, "Kevin K." ***@***.***> wrote: @BurntSushi <https://github.com/BurntSushi> I found a solution that seems to work! 🎉 term_size can read stdout, and if that fails try *stdin*...if *that* fails then try stderr...*then* give up. Works in my tests so far. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#442 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAb34oa1sa0OdFtgHVn28d9J-BOP-HB3ks5ruRl9gaJpZM4M4C3P> .