* src/dircolors.hin: Add screen.Eterm.
Reported-by: Kfir Lavi
Signed-off-by: Mike Frysinger
---
src/dircolors.hin |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/dircolors.hin b/src/dircolors.hin
index 8b4a645..bab7c9b 100644
--- a/src/dircolors.hin
+++ b/src/dircol
On 07/19/11 15:24, Pádraig Brady wrote:
> How about just adding a module to gnulib
> where others might find it useful too?
Yes, that's better, thanks. Could you please add
Jim and me to the maintainer list?
2011/7/19 Pádraig Brady :
> On 19/07/11 23:00, James Youngman wrote:
>> 2011/7/17 Paul Eggert :
>>> On 07/17/11 05:31, Pádraig Brady wrote:
Well my reasoning for having "0" mean don't timeout,
was to have an easy way in scripts to specify no timeout
>>>
>>> That's a good thing to have, bu
On 19/07/11 19:45, Paul Eggert wrote:
> On 07/19/11 04:00, Pádraig Brady wrote:
>
>> + if (timer_create (CLOCK_REALTIME, NULL, &timerid) == -1)
>> +error (EXIT_FAILURE, errno, _("error in timer_create"));
>> + if (timer_settime (timerid, 0, &its, NULL) == -1)
>> +error (EXIT_FAILURE, err
On 19/07/11 23:00, James Youngman wrote:
> 2011/7/17 Paul Eggert :
>> On 07/17/11 05:31, Pádraig Brady wrote:
>>> Well my reasoning for having "0" mean don't timeout,
>>> was to have an easy way in scripts to specify no timeout
>>
>> That's a good thing to have, but it could be specified in
>> a di
2011/7/17 Paul Eggert :
> On 07/17/11 05:31, Pádraig Brady wrote:
>> Well my reasoning for having "0" mean don't timeout,
>> was to have an easy way in scripts to specify no timeout
>
> That's a good thing to have, but it could be specified in
> a different way. One possibility is the '1' (digit 1
Hi,
On Jul 19, 2011, at 06:00, Pádraig Brady wrote:
>
> We could remove the setitimer stuff altogether and
> just support 1 second resolution on darwin et. al.
> That's by far the most common use case anyway.
If I may, since I am an OSX user [1] [2] ,
I cast my "vote" here. ;)
[1] I am planni
> -Original Message-
> From: Paul Eggert [mailto:egg...@cs.ucla.edu]
> Sent: Saturday, July 16, 2011 3:12 AM
Sorry for the delay, got distracted with $DAYJOB
> To: Pádraig Brady
> Cc: Joachim Schmitz; 9...@debbugs.gnu.org
> Subject: Re: bug#9076: coreutils-8.12 uses SA_RESETHAND and SA_RE
Pádraig Brady writes:
>On 19/07/11 08:13, Hallvard B Furuseth wrote:
>> Coreutils 5.12 gets that right in my test:
>> 1st output line is "12345671".
>
> That's incorrect according to POSIX.
> The space should be converted to tab as
> it's followed by a blank.
Duh, sorry. I read "...immediately p
On 18/07/11 23:17, Pádraig Brady wrote:
> On 18/07/11 17:44, Paul Eggert wrote:
>> On 07/18/11 03:01, Pádraig Brady wrote:
>>> I'll apply this soon.
>>
>> Thanks for doing that. Some comments:
>>
>> I see that my bug report was incoherent, as it was talking about
>> nanosecond resolution and setiti
On 19/07/11 08:13, Hallvard B Furuseth wrote:
> Pádraig Brady writes:
>> Actually POSIX is quite specific and my reading
>> is that a space before tabstop should be preserved
>> iff it's the only blank before tabstop and it
>> isn't followed by another blank.
>>
>> In that sense, both i18n patched
Hallvard B Furuseth writes:
> Coreutils 5.12 gets that right in my test:
> 1st output line is "12345671".
Oops, coreutils 8.12.
> But now that you mention it, an option to never
> output the sequence would be nice.
--
Hallvard
Pádraig Brady writes:
> Actually POSIX is quite specific and my reading
> is that a space before tabstop should be preserved
> iff it's the only blank before tabstop and it
> isn't followed by another blank.
>
> In that sense, both i18n patched unexpand
> and current coreutils get this wrong.
Cor
13 matches
Mail list logo
