tail -f session can possibly leave the terminal window in a unstable condition. Steps to reproduce the problem: 1) tail -f any file on the system 2) Copy some part of it or maybe any other text to your clipboard 3) Keep pasting the content inside the console where you are doing the tail -f on the file 4) At some point it'll get stuck and you won't be able to Ctrl + C or Ctrl + Z out of it. 5) Only option I've seen so far is restarting the terminal window.
Seriously - you are using 0.4.7?! If so, please upgrade immediately.
Not sure if upgrading here will make a difference... I assume the behavior is the same in other terminal emulators (xterm, urxvt, konsole...) as well. Pasting large amounts of data to terminals sucks for various reasons, most of them being kernel limitations or even kernel bugs. In this particular case it's simply that there's a maximum tty buffer size in the kernel for characters that the terminal emulator can send towards the application before the app consumes them. The concept is pretty much the same as with named and unnamed pipes. In MS DOS 6.22-ish this was like maybe 10-15 characters (perhaps still the same in Windows's DOS/Terminal/cmdline window, whatever it's called), you might remember that trying to type more characters in advance resulted in beeping. In Linux this limit is probably 4 or 8 kB. I'm afraid you just have to live with it. Don't paste data to "tail -f" (why would you? other than accidentally), or if you do, you might need to manually kill the "tail" process, or close the terminal tab.
Killing "tail" is actually a bad idea, don't do that. It causes the buffered paste data to be executed by the shell.
Well I am on a computer with restrictions on it for upgrading, but I can try upgrading to check on a different machine. However, as Egmont pointed out that this also might not solve the problem, I guess I'll give that a pass. Reported the bug to bring out the issue into light in case it was just an xfce thing. Happy to get the explanation though. Thanks!
(In reply to Egmont Koblinger from comment #2) > Not sure if upgrading here will make a difference... I assume the behavior > is the same in other terminal emulators (xterm, urxvt, konsole...) as well. > > Pasting large amounts of data to terminals sucks for various reasons, most > of them being kernel limitations or even kernel bugs. > > In this particular case it's simply that there's a maximum tty buffer size > in the kernel for characters that the terminal emulator can send towards the > application before the app consumes them. The concept is pretty much the > same as with named and unnamed pipes. In MS DOS 6.22-ish this was like maybe > 10-15 characters (perhaps still the same in Windows's DOS/Terminal/cmdline > window, whatever it's called), you might remember that trying to type more > characters in advance resulted in beeping. In Linux this limit is probably 4 > or 8 kB. > > I'm afraid you just have to live with it. Don't paste data to "tail -f" (why > would you? other than accidentally), or if you do, you might need to > manually kill the "tail" process, or close the terminal tab. Thanks for the explanation. Well I have this habit of doing a tail -f on the log files while I debug something and I'll be typing out some temporary markers just so that I can scroll up and keep track. That's when I came across this issue.
(In reply to Egmont Koblinger from comment #3) > Killing "tail" is actually a bad idea, don't do that. It causes the buffered > paste data to be executed by the shell. Yup that is correct
I would still try to upgrade the terminal as some other things may be fixed in newer versions. As for this one - how long are the text blocks that you are pasting? I've quickly tried it today with version 0.8.1 tail'ing a ~70 meg file and randomly pasting a short string into the output, and seen no issues with that.
(In reply to Igor from comment #7) > I would still try to upgrade the terminal as some other things may be fixed > in newer versions. > > As for this one - how long are the text blocks that you are pasting? > I've quickly tried it today with version 0.8.1 tail'ing a ~70 meg file and > randomly pasting a short string into the output, and seen no issues with > that. For me it's freezing after I paste 4 KB of data. Can you try something more than that? I'll also upgrade at my earliest convenience to the latest version.
(In reply to Chintan Pathak from comment #5) > Thanks for the explanation. Well I have this habit of doing a tail -f on the > log files while I debug something and I'll be typing out some temporary > markers just so that I can scroll up and keep track. That's when I came > across this issue. Wow, that's a really unexpected, interesting use case :) One thing you can do is open another terminal, and execute cat < /dev/pts/[wherever "tail -f" is running] > /dev/null This "cat" command eats the characters from the buffer that "tail" is not eating. (If both of them were reading it, it'd be a race where each line is read by whoever happens to be faster.) The tty number can be figured out e.g. from "ps ax", although I personally always have it as the title of my terminal, it's the most useful title a terminal emulator hacker guy could imagine :) You can sure execute the "cat" in advance in the same terminal too, but you'll need maybe a nohup or some similar wrapper (I'm lazy to figure this out right now), since by default a command sent to the background is stopped as soon as it tries to read from the terminal. I guess the same result can also be achieved by flushing the terminal buffer, see tty_ioctl(4) (not sure exactly which one from there).
(In reply to Chintan Pathak from comment #8) > (In reply to Igor from comment #7) > > I would still try to upgrade the terminal as some other things may be fixed > > in newer versions. > > > > As for this one - how long are the text blocks that you are pasting? > > I've quickly tried it today with version 0.8.1 tail'ing a ~70 meg file and > > randomly pasting a short string into the output, and seen no issues with > > that. > > For me it's freezing after I paste 4 KB of data. Can you try something more > than that? > > I'll also upgrade at my earliest convenience to the latest version. You are right, I was able to reproduce the issue with a larger text block. Upgrading the version won't help, unfortunately. Also, the issue happens in gnome-terminal and the vte app as well. This means that it's related to the vte widget, not to xfce4-terminal. I'm afraid I cannot help here, sorry.
I'm pretty certain xterm, konsole etc. also behave the same way. It's not a vte issue but a kernel issue.
Closing the bug report as it looks like a kernal thing and not something related to xfce, gnome or any of them.
(In reply to Egmont Koblinger from comment #11) > I'm pretty certain xterm, konsole etc. also behave the same way. It's not a > vte issue but a kernel issue. Yeah, I think you are right. Sorry for involving vte :)