On 2/17/13 7:46 PM, Pádraig Brady wrote:
>>> I notice the following will wait for 5 seconds for
>>> the timeout process to end with SIGALRM, rather than
>>> immediately due to kill sending the SIGTERM.
>>
>> I think the way to approach this is to change the SIGTERM handling from
>> straight SIG_IG
On 02/17/2013 10:00 PM, Chet Ramey wrote:
On 2/9/13 12:02 AM, Pádraig Brady wrote:
$ rpm -q kernel glibc bash
kernel-2.6.40.4-5.fc15.x86_64
glibc-2.14.1-6.x86_64
bash-4.2.10-4.fc15.x86_64
I notice the following will wait for 5 seconds for
the timeout process to end with SIGALRM, rather than
imm
On 2/13/13 12:44 PM, Matei David wrote:
> Another thing I tried was to open a fd with <() and use it later in a shell
> function. Surprisingly, the fd disappears (is closed) if the shell executes
> something unrelated in subshell:
This was reported a while back
http://lists.gnu.org/archive/html/b
On 2/9/13 12:02 AM, Pádraig Brady wrote:
> $ rpm -q kernel glibc bash
> kernel-2.6.40.4-5.fc15.x86_64
> glibc-2.14.1-6.x86_64
> bash-4.2.10-4.fc15.x86_64
>
> I notice the following will wait for 5 seconds for
> the timeout process to end with SIGALRM, rather than
> immediately due to kill sending
On 2/17/13 4:50 PM, Egmont Koblinger wrote:
> I can't see it in
> http://git.savannah.gnu.org/cgit/bash.git/tree/lib/readline/display.c?h=devel
> -- this means that either I'm looking at the wrong place, or you applied a
> different fix. Anyway, I'm glad if it's fixed :)
My changelog says I appl
On 2/16/13 9:57 AM, Chris Down wrote:
> Count me also in favour of removal of this section. At best the entire
> section needs a complete rewrite, but why on earth we have a whole section
> dedicated to a nonstandard external tool is kind of baffling.
Consider the FSF's perspective. The fact tha
On 2/16/13 3:50 AM, Pierre Gaston wrote:
> I don't quite see the point of having gnu parallel discussed in the
> bash reference manual.
> http://www.gnu.org/software/bash/manual/bashref.html#GNU-Parallel
I was asked to add that in May, 2010 by Ole Tange and Richard Stallman.
Chet
--
``The lyf s
On Sun, Feb 17, 2013 at 10:43 PM, Chet Ramey wrote:
> On 2/17/13 8:37 AM, Egmont Koblinger wrote:
> > Hi Chet,
> >
> > Friendly ping - could you please look at the bug description below and
> > review the attached patch? This is a really trivial bugfix (just 1
> > character), should be obvious t
On 2/14/13 7:57 PM, Richard Tollerton wrote:
> This is probably not a good thing to be doing in the first place (I ran
> into this before realizing that GROUPS was a special variable):
Not only is GROUPS a special variable, assignments to it are disallowed.
Still, the shell shouldn't core dump whe
On 2/17/13 8:37 AM, Egmont Koblinger wrote:
> Hi Chet,
>
> Friendly ping - could you please look at the bug description below and
> review the attached patch? This is a really trivial bugfix (just 1
> character), should be obvious to verify.
This change has been in the devel branch for a few wee
On 1/21/13 3:16 PM, Egmont Koblinger wrote:
> Hi,
>
> On a fully UTF-8 environment, in certain easily reproducible cases, the
> command line becomes messed up (the cursor ends up in the wrong column, and
> from then on it's tons of cumulative mistakes). I'm using bash-4.2.42, but
> the bug also a
Hi Chet,
Friendly ping - could you please look at the bug description below and
review the attached patch? This is a really trivial bugfix (just 1
character), should be obvious to verify.
Thanks a lot,
egmont
On Tue, Jan 29, 2013 at 2:06 PM, Egmont Koblinger wrote:
> Hi,
>
> In UTF-8 environm
Hi Chet,
Friendly ping - could you please look at this bug and patch, too? I know
it's bit more complicated, and I haven't finished the non-UTF part, but
based on my findings I believe this should be really straightforward for
you.
I know bash's UTF-8 support is contributed code and is quite com
13 matches
Mail list logo
