Interrupting hexyl with ^C leaves ugly remnant

sharkdp / hexyl

A command-line hex viewer

Apache License 2.0

9.07k stars 227 forks source link

Interrupting hexyl with ^C leaves ugly remnant #35

Closed vi closed 1 year ago

vi commented 5 years ago

screenshot

It should probably handle SIGINT and terminate the output as if it was EOF (but maybe with some mark):

│00001410│ 57 37 f9 ae 0b ae 6c 8a ┊ df 0e d8 20 15 f1 d7 f6 │W7××•×l×┊×•× •×××│
│00001420│ a5 5e 99 b0 bd bf 22 a7 ┊ b2 e0 ab ^C             | ×^×××"×┊×××^C   |

sharkdp commented 5 years ago

Thank you for reporting this. This should be easy to fix, yes.

sharkdp commented 5 years ago

Fixed in v0.4.0.

vi commented 5 years ago

screenshot

Reproducible in multiple terminal emulators. Consistenly nice only in linux text terminal.

DannyCork commented 5 years ago

This is what ctrl-c looks like on Mac OS X

Screenshot 2019-03-16 at 19 15 49

sharkdp commented 5 years ago

If somebody has an idea how to fix this, let me know.

domenpk commented 5 years ago

Well, part of the problem is synchronous handling of ctrl+c. If you move process exit into the handler, the situation improves. I'm not sure what's actually safe to be called from a signal handler in Rust though (normally described in: man 7 signal-safety).

It's still a bit of a problem, I assume because of stdout buffering. May need some uglier tricks to work around (setbuf?).

secworks commented 4 years ago

A possibly related issue is that on MacOS, when running hexyl without any input the application can't be terminated. Like this:

This is with hexyl 0.6.0 on MacOS 10.14.6

sharkdp commented 4 years ago

@secworks That looks like a different bug to me (much less esoteric than this one; thank you for reporting it). It would be great if you could create a new ticket.

sharkdp commented 4 years ago

With the changes in #84, this is now open again. In my terminal and on zsh, this is not an issue. But apparently it causes problems in some terminal/shell combinations.

sandorex commented 4 years ago

@sharkdp Have you tried using alternative buffer when opening the application ? The smcup / rmcup capability of the terminal ?

bjorn3 commented 4 years ago

Using an alternative buffer would mean that you have to handle scrolling yourself and you can't see the output anymore after you exit hexyl.

sandorex commented 4 years ago

I guess the only other thing i can think of is disabling echo and reenabling it after quitting, but you probably already did that right?

sharkdp commented 4 years ago

I'm not sure what that means?

sandorex commented 4 years ago

echo is when you press a key it displays on the terminal, but i think it is already disabled otherwise any key would be visible on a press

bjorn3 commented 4 years ago

Echo is enabled. I can still type stuff while I run cat /dev/zero | pv -q -L 16 | hexyl (read zeros at a rate of 16 bytes per second)

sandorex commented 4 years ago

@bjorn3 You are right

I've been able to test it with little bash (does not work on zsh)

orig=$(stty -g)
stty -echo
hexyl /dev/urandom
stty $orig

And it doesnt show the ^C anymore

sharkdp commented 1 year ago

I'm closing this due to inactivity. And because I can not reproduce this on my machine. Please feel free to comment in case it should be re-opened.