Chet Ramey wrote:
On 5/22/14, 10:32 PM, Linda Walsh wrote:
The "beauty" of the bash-WINCH handler was that it worked
with ANY window manager or NO window manager.
Sure. It just abused the idea of running safe code in a signal handler
context.
It doesn't have to.
P
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 05/23/2014 05:05 PM, Dan Douglas wrote:
On Friday, May 23, 2014 10:48:11 AM Chet Ramey wrote:
On 5/23/14, 10:17 AM, Ondrej Oprala wrote:
Hi, there've recently been a few bug reports against bash on RH BZ,
saying that bash can't handle infinite recursion the way zsh or ksh can.
Looking at ex
On Friday, May 23, 2014 10:48:11 AM Chet Ramey wrote:
> On 5/23/14, 10:17 AM, Ondrej Oprala wrote:
> > Hi, there've recently been a few bug reports against bash on RH BZ,
> > saying that bash can't handle infinite recursion the way zsh or ksh can.
> >
> > Looking at execute_cmd.c, there are the f
On 05/23/2014 04:48 PM, Chet Ramey wrote:
On 5/23/14, 10:17 AM, Ondrej Oprala wrote:
Hi, there've recently been a few bug reports against bash on RH BZ,
saying that bash can't handle infinite recursion the way zsh or ksh can.
Looking at execute_cmd.c, there are the funcnest{,_max} variables
an
On 5/23/14, 10:17 AM, Ondrej Oprala wrote:
> Hi, there've recently been a few bug reports against bash on RH BZ,
> saying that bash can't handle infinite recursion the way zsh or ksh can.
>
> Looking at execute_cmd.c, there are the funcnest{,_max} variables
> and a piece of code using them in exe
On Friday, May 23, 2014 04:17:12 PM Ondrej Oprala wrote:
> Hi, there've recently been a few bug reports against bash on RH BZ,
> saying that bash can't handle infinite recursion the way zsh or ksh can.
They come up here at least a few times a year. E.g.
https://lists.gnu.org/archive/html/bug-bash
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
Hi, there've recently been a few bug reports against bash on RH BZ,
saying that bash can't handle infinite recursion the way zsh or ksh can.
Looking at execute_cmd.c, there are the funcnest{,_max} variables
and a piece of code using them in execute_function().
Will funcnest_max be set to non-0
On 5/22/14, 10:32 PM, Linda Walsh wrote:
> The "beauty" of the bash-WINCH handler was that it worked
> with ANY window manager or NO window manager.
Sure. It just abused the idea of running safe code in a signal handler
context.
Chet
--
``The lyf so short, the craft so long to lerne.'' - C
On 05/23/2014 02:32 AM, Libor Pechacek wrote:
> +++ b/general.c
> @@ -699,7 +699,10 @@ polite_directory_format (name)
>int l;
>
>home = get_string_value ("HOME");
> - l = home ? strlen (home) : 0;
> +
> + /* remove trailing slashes from $HOME before comparisons */
> + for (l = home ?
On Fri 16-05-14 09:13:34, Chet Ramey wrote:
> On 5/16/14, 5:22 AM, Libor Pechacek wrote:
>
> > Bash Version: 4.2
> > Patch Level: 46
> > Release Status: release
> >
> > Description:
> > Bash prompt always shows full path in prompt instead of tilde
> > abbreviation when $HOME ends with sla
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
14 matches
Mail list logo
