Chet Ramey wrote:
I think you misunderstand. Applications, in this context, are those
programs that link with readline ...
Ah... of course, wasn't thinking of apps in that sense. Was trying
to figure out interactions between programs launched by bash and
signal handling in bash. Com
On 5/22/14, 10:19 PM, Linda Walsh wrote:
>> 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 t
Andreas Schwab wrote:
Linda Walsh writes:
I think you have that backwards... pselect allows blocking
the signal. The default behavior is 'undefined'.
What do you mean with 'undefined'? pselect installs the exact signal
mask specified, which allows you to atomically *unblock* a si
Linda Walsh writes:
> I think you have that backwards... pselect allows blocking
> the signal. The default behavior is 'undefined'.
What do you mean with 'undefined'? pselect installs the exact signal
mask specified, which allows you to atomically *unblock* a signal while
waiting for inp
Greg Wooledge wrote:
On Thu, May 22, 2014 at 06:02:42AM -0700, Linda Walsh wrote:
This allows me to dynamically see what I'm doing when I resize a window
if I am going for a specific size (which happens usually after I've
expanded it for some reason, and am now trying to size it back down.
f
Egmont Koblinger wrote:
Hi,
Disclamer: this might be Linux specific, I don't know too much about
other Unixes.
SIGWINCH *does* interrupt system calls (easily causing a whole lot of
headache for many people), unless the signal is blocked or ignored (as
it is by default). And there's a cool ps
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
On 5/22/14, 4:47 PM, Linda Walsh wrote:
>
>
> Chet Ramey wrote:
>> On 5/22/14, 1:16 AM, Linda Walsh wrote:
>>
>> Further complicating things is the fact that there is not any portable
>> way to specify that SIGWINCH should interrupt system calls. There is
>> the SA_RESTART flag that says *not* t
Chet Ramey wrote:
On 5/22/14, 1:16 AM, Linda Walsh wrote:
Further complicating things is the fact that there is not any portable
way to specify that SIGWINCH should interrupt system calls. There is
the SA_RESTART flag that says *not* to fail with EINTR, but there is no
portable flag that has
On 5/22/14, 1:16 AM, Linda Walsh wrote:
>
>
> Chet Ramey wrote:
>> On 5/20/14, 8:28 AM, Egmont Koblinger wrote:
>>> Hi,
>>>
>>> Execute this in an interactive bash and then resize the window:
>>> trap 'stty size' winch
>>>
>>> In bash-4.2, the trap was executed immediately upon resize. In
>>> ba
On Thu, May 22, 2014 at 06:02:42AM -0700, Linda Walsh wrote:
> This allows me to dynamically see what I'm doing when I resize a window
> if I am going for a specific size (which happens usually after I've
> expanded it for some reason, and am now trying to size it back down.
fvwm2 (which I've been
On Thu, May 22, 2014 at 4:02 PM, Linda Walsh wrote:
>
>
> Pierre Gaston wrote:
>
>>
>> As I understand it, this is now broken in 4.3?:
>>
>> # display new size of terminal when resized
>> function showsize () {\
>> local s=$(stty size); local o="(${s% *}x${s#* })"; s="$
Pierre Gaston wrote:
As I understand it, this is now broken in 4.3?:
# display new size of terminal when resized
function showsize () {\
local s=$(stty size); local o="(${s% *}x${s#* })"; s="${#o}";\
echo -n $o; while ((s-- > 0));do echo -ne "\b"; done; \
}
On Thu, May 22, 2014 at 8:16 AM, Linda Walsh wrote:
>
>
> Chet Ramey wrote:
>
>> On 5/20/14, 8:28 AM, Egmont Koblinger wrote:
>>
>>> Hi,
>>>
>>> Execute this in an interactive bash and then resize the window:
>>> trap 'stty size' winch
>>>
>>> In bash-4.2, the trap was executed immediately upon r
Chet Ramey wrote:
On 5/20/14, 8:28 AM, Egmont Koblinger wrote:
Hi,
Execute this in an interactive bash and then resize the window:
trap 'stty size' winch
In bash-4.2, the trap was executed immediately upon resize. In
bash-4.3, it is delayed until the next keypress.
http://lists.gnu.org/ar
On 5/20/14, 8:28 AM, Egmont Koblinger wrote:
> Hi,
>
> Execute this in an interactive bash and then resize the window:
> trap 'stty size' winch
>
> In bash-4.2, the trap was executed immediately upon resize. In
> bash-4.3, it is delayed until the next keypress.
http://lists.gnu.org/archive/html
Hi,
Execute this in an interactive bash and then resize the window:
trap 'stty size' winch
In bash-4.2, the trap was executed immediately upon resize. In
bash-4.3, it is delayed until the next keypress.
Is this an intentional, expected change? There seems to be no
relevant entry in NEWS.
I us
17 matches
Mail list logo
