Bug 240758

> Also, add an option to post a desktop
> notification; it would be useful when waiting for a lengthy task to complete.

Konsole has a similar existing feature - it can monitor the terminal application for 'silence' (a period of inactivity) and show a notification when that happens.

> It would be nice if Konsole changed something in its chrome
> when is the front process is waiting for input. 

Detecting in a sufficiently robust and reliable way whether a process is waiting for input might be an interesting exercise.  Suggestions welcome - bearing in mind that the shell might be remote (via ssh) and the style of prompt will vary depending on the application that is producing it.

(In reply to comment #1)
> > Also, add an option to post a desktop
> > notification; it would be useful when waiting for a lengthy task to complete.
> 
> Konsole has a similar existing feature - it can monitor the terminal
> application for 'silence' (a period of inactivity) and show a notification when
> that happens.
> 
> > It would be nice if Konsole changed something in its chrome
> > when is the front process is waiting for input. 
> 
> Detecting in a sufficiently robust and reliable way whether a process is
> waiting for input might be an interesting exercise.  Suggestions welcome -
> bearing in mind that the shell might be remote (via ssh) and the style of
> prompt will vary depending on the application that is producing it.

You can query the frontmost process associated with the pseudoterminal and test whether S of $(ps -l) is 'S'.

> It would be nice if Konsole changed something in its chrome 
> when is the front process is waiting for input.  

I do not quite understand the point. Most of the time, shell and other interactive apps are always waiting for input from user. So that is the normal state. Is it useful to keep reminding of users: "you are in normal state now" ?

Most of the time, shell and other interactive applications are doing something really long (e.g. running a build script, solving a differential equation, downloading a large set of files from the network — whatever computers are made for) and I would welcome a notification that the shell is ready to receive the next command.

As a workaround, you can schedule a batch job instead and get the notification by e-mail but it requires the at daemon to run and it is not that convenient at all (you get the error message by e-mail when the command immediately fails because you have mistyped it).

I hope I have enlightened Jekyll in this matter, so I reopen.

(In reply to comment #4)
> 

While I agree the notification for those listed examples is useful, I do not agree with that 'Most of time'. Such long running commands are the minority, not the majority. Most commands executed in the shell are either interactive(vim,less,mc), or finish its work quickly(ls,cat,date) and the shell waits for user input again almost immediately. 

So I would repeat my opinion again: waiting for user input is the most common state. If the proposed notification for waiting for input is done, then each time after users have executed 'ls','pwd', or 'date' and shell waits user input again, should they be notified "the shell is waiting for input"? That would be more boring than helpful. That notification may be designed as one-shot to avoid such annoyance, of course.

And I think the current 'Monitor activity/silence' works well for monitoring most long-running commands. For example, I can use 'Monitor silence' to notify myself that wget(1) or make(1) has finished its job. Or, I can use 'Monitor activity' to monitor some long-running calculation which does not  generate output until it finishes.There may be some situations where 'Monitor activity/silence' is not good enough, but I think they are the minority of the minority.

That proposal sounds nice, but I do not think it is good/useful enough to pay off the implementation cost and the potential side effect.

(In reply to comment #5)

> So I would repeat my opinion again: waiting for user input is the most common
> state. If the proposed notification for waiting for input is done, then each
> time after users have executed 'ls','pwd', or 'date' and shell waits user input
> again, should they be notified "the shell is waiting for input"? That would be
> more boring than helpful. That notification may be designed as one-shot to
> avoid such annoyance, of course.

The notification should appear only if the Konsole window does not have focus and only after some waiting period (say 5 min default).

reopen when someone provides a patch