Bug 245064 - clearing scrollback kills programs
Summary: clearing scrollback kills programs
Status: RESOLVED WORKSFORME
Alias: None
Product: konsole
Classification: Applications
Component: general (show other bugs)
Version: 2.4.3
Platform: openSUSE Linux
: NOR crash
Target Milestone: ---
Assignee: Konsole Developer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-07-18 19:25 UTC by bkorb
Modified: 2010-07-21 19:32 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description bkorb 2010-07-18 19:25:09 UTC
Version:           2.4.3 (using KDE 4.4.4) 
OS:                Linux

You have removed "clear scrollback" and combined it with "& reset"
and obviously didn't discuss it with very many users beforehand.
I regularly clear the scrollback when I see the output getting
to the point where something interesting is about to happen.
It is much easier than saving the output to a file and then searching
through it all (often times, anyway).  THIS MISSING BEHAVIOR IS
NOT ACCEPTABLE.  I surely wish you-all would solicit feedback
*before* disabling features the people use.  (This not being the
first or even second time I've encountered severe impediments
due to sudden obsolescence of features I use.)

Reproducible: Always

Steps to Reproduce:
run a program with lots and lots and lots of output but has clear
markers where different phases of operation is happening.  Try
to clear the scrollback half way through.

Actual Results:  
The program is killed and you get a shell prompt.

Expected Results:  
The scrollback would be cleared and the program would continue

OS: Linux (x86_64) release 2.6.34-12-desktop
Compiler: gcc
Comment 1 Robert Knight 2010-07-19 19:49:18 UTC
The 'Actual Results' you describe are not intended behavior.  It sounds like a bug somewhere.

> You have removed "clear scrollback" and combined it with "& reset"
> and obviously didn't discuss it with very many users beforehand.

The majority of the KDE developers and testers are heavy terminal users.  If a change gets made which causes frustration for many users we usually do hear about it quickly.

> The program is killed and you get a shell prompt.

I was not able to reproduce when testing locally 'find /' and a few other long-running commands.  Pressing Ctrl+Shift+X mid-way through execution clears scrollback but does not kill the command.

Can you give an example of a specific command which exhibits this behavior and can you confirm which keyboard shortcut you have bound to this action?
Comment 2 bkorb 2010-07-19 21:13:31 UTC
In the 3.5.x Konsole that I know and love, the "Edit" menu has an entry, "Clear History" that does exactly what I want.  In 4.2, that was moved to the "Scrollback" menu and was re-titled "Clear Scrollback".  I found it, but only after hunting around for a while.  OpenSuSE went to 4.4 and "Clear Scrollback" is gone and instead the entry that seems similar is "Clear Scrollback & Reset".  When I do a huge build, a la:

 ../configure && make && make distcheck

I tried to clear the scrollback after the several hundred lines of configure cruft have scrolled past using the pull down menu.  After I do that, the build has stopped and I have a command prompt.  I don't use "hot keys", though C-S-X probably is bound to the command.
Comment 3 Robert Knight 2010-07-19 21:30:50 UTC
> When I do a huge build, a la:
> ../configure && make && make distcheck

I tried reproducing here using an an automake-based project, pressing Ctrl+Shift+X and using the menu item during both the ./configure and make stages but did not experience the problem.

This is under Ubuntu Lucid in case it is relevant.
Comment 4 bkorb 2010-07-19 21:41:49 UTC
``This is under Ubuntu Lucid in case it is relevant.''
It may be, even if we would both hope not.  My platform
is the several-days-old OpenSuSE 11.3.  Is there anything
I can do to improve the diagnostic info?
Comment 5 bkorb 2010-07-21 19:32:30 UTC
Sorry for the bother.  I fiddled with it again last night, and what happened every time does not happen any more.  This means it is possible to get it into a funny state where "clear & reset" sends some signal to the process, but it is not a highly reproducible result.  In other words, unless I can figure out how it happened, there's nothing that can be done.