[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: winch trap delayed until keypress

From: Linda Walsh
Subject: Re: winch trap delayed until keypress
Date: Thu, 22 May 2014 19:19:38 -0700
User-agent: Thunderbird

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?

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"

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


printf "(%s)" "$key"

exit 0

# vim: ts=2 sw=2

reply via email to

[Prev in Thread] Current Thread [Next in Thread]