Re: winch trap delayed until keypress

[Linda Walsh]

Chet Ramey wrote:

> The bash-4.3 solution is acceptable.  I'm not really enthusiastic about
> making the shell multi-threaded like that.
---
        Maybe not, but apps aren't going multithreaded these
days?  Parallel programming is where it's at! ;-)

        If you limit the alternate threads to specific functions,
it can improve reliability.

> > If bash doesn't do it, how can a script get the notification?
>
> Scripts aren't really the problem here.
---
        They are in one of my common use cases.

        Heck, in the application I was mentioning, you'll like this
irony, I think, -- one of the early "hacks" I did to get a reliable
readkey (1 key read w/timeout) that was WINCH safe, was to
CALL a bash script(@end) that set/reset the term mode and used bash's
timed read.  I.e. bash was SPECIFICALLY used *for* that feature.  When
I got the program fully working, I had to abandon that method -- too
high on the overhead.).

> We're mostly talking about the
> interaction between readline and the applications that use it. 
----
        I'm not sure I see the problem there -- since the application
runs "after bash" (i.e. bash forks&execs it, then waits for it to return
in the normal foreground case), wouldn't the application be able to
install whatever signal handling it wants and possibly interfere w/bash
getting the signal, vs. bash causing app interferences?


> While
> you can use readline in a script -- and there is a pending bug with
> readline and timeouts in scripts when called by the read builtin -- it's
> not the primary use case.  And SIGWINCH is the only signal subject to
> this problem.
---

Wait.. there is a pending bug w/readline and timeouts, (i.e. SIGALARM?) and
SIGWINCH is the only one -- is the bug w/readline & timeouts, or only
in the presence of SIGWINCH?  It might, related to the same problem I
ran into perl's 'ReadKey' ... I'll tell ya, putting the reader
in a safe process space and using pipes really improved performance (best
had been about 3-5% cpu usage w/1 update/5 seconds.  Now that's down to under
1% @ 1update/5s).

--- readkey hack for reliable readkey from perl (don't know if this
would work under 4.3, either)....
#!/bin/bash --norc
# testin [<T.s>]  -       takes [optional] wait time <T.s> (positive decimal)
#   polls for a KEY;
#     if a KEY is pressed, its value is echoed on stdout as '(KEY)'
#     if a timeout occurs w/no input, '(undef)' is echoed on stdout
#     Note: a press of Enter, will likely result in '()' being returned
#
# Requires: uses bash's built-in read features!
#               v0.1.3+4 - (2013-10-13)
#               v0.1.2   - (2012-07-01)
#               v0.1.1   - initial version 2011-05-17
#
# (prog note) timeout, below, must NOT be declared with 'int' attribute

shopt -s expand_aliases
alias int=declare\ -i           const=declare\ -r               sub=function
Stty="$(type -P stty)"

declare timeout=0; (($#)) && timeout="$1"

sub set_input_raw_noecho () { "$Stty" raw -echo; }
sub set_input_normal () { "$Stty" cooked echo; }

set_input_raw_noecho || { int stat=$?; echo "(error)" ; exit $stat; }

declare key="undef"
IFS=""

if [[ $timeout == 0 ]] && read -t0 ; then
        read -n1 -t1 key
elif ! read -n1 -t$timeout key; then
        key="undef"
fi

set_input_normal

printf "(%s)" "$key"

exit 0

# vim: ts=2 sw=2