Re: [tin 1.8.x/1.9.x] terminal confused: popen(), SIGSTOP and perl

On 22.07.2009, at 19:52, Urs Janßen wrote:

> When I pipe an article through 'cat|less' and press ^Z while being
> in less I can fg back to tin and continue as expected. When I pipe
> an article through 'perl -ne "print $_;"|less' and press ^Z while
> being in less tin is unusable after fg.
> 	kill -9 `ps xauww|awk'/[l]ess/{print $2}'`
> in another terminal usualy ends tin and leaves it's terminal in
> unusable status, reset helps.
>
> perls fault? tins fault?

I'm not shure whether this is tins fault but it can be fixed by  
setting the signal handler to SIG_DFL before popen() and back to tins  
own after pclose() by calling set_signal_catcher(FALSE|TRUE). This is  
what we are doing in invoke_cmd(). Attached patch does this.

Some other issues (more or less related to signal handling) are fixed  
too:

tin -z (start_any_unread): When receiving SIGWINCH while being in  
check_start_save_any_news() tin crashs. index_group() sets  
signal_context to cArt and read_overview() calls handle_resize().  
handle_resize() invokes show_art_message(curr_group->name), but  
curr_group is not valid at this stage. Fixed by changing this to  
CURR_GROUP.name.

When receiving SIGWINCH right before get_server(), s_gets() returnes  
NULL and one get the reconnection prompt. You can see this by  
starting tin, entering a (large) group and resize the terminal while  
"Group x.y ('q' to quit)..." is displayed. Unfortunately, you don't  
see the reconnection prompt until you hit cursor up or down because  
handle_resize() clears the screen immediately after the reconnection  
prompt. Fixed by 'starting' the while loop again if errno==EINTR.

When receiving a SIGWINCH while being in prompt_continue() (for  
instance after a shell escape '!') the current menu is redrawn. This  
looks ugly because prompt_continue() sets cmd_line to TRUE. Fixed by  
setting signal_context temporary to cMain.

prompt_continue(): When suspending tin while being in prompt_continue 
() and 'fg' back to tin, the prompt ("press <RETURN> to continue...")  
is not redrawn. Fixed by adding a new input_context and redraw the  
prompt *only* after a suspend (SIGWINCH is not affected).

prompt_continue(): When not using RETURN to leave the prompt and  
get_arrow_key() is involved, results are unexpected. For instance,  
doing a shell escape '!' and 'ls' from selection level and answer the  
prompt with KEY_RIGHT (cursor right) ends up in "Mark group x.y as  
read? (Y/n)". prompt_continue() sets cmd_line to TRUE. ReadCh()  
(tcurses.c) calls cmdReadCh() (ReadCh() from curses.c). In this case  
we have to use get_arrow_key() from curses.c too.

prompt_continue(): An additional newline was needed, otherwise the  
prompt message was left under the shell prompt after leaving tin.

handle_suspend() now uses EndWin()/InitWin when needed. This looks  
better after CTRL-C and prevents trouble. Here, a check for ! 
batch_mode || !cmd_line is needed, because during  
check_start_save_any_news() batch_mode is TRUE but curses/windowing  
is 'up' and prompt_continue() sets cmd_line to TRUE and windowing is  
'up' too.

prompt_yn(): The prompt message is not redrawn after SIGWINCH. Fixed  
by adding prompt_yn_redraw() and calling this from handle_redraw().

Dennis