On 03/08/2010 03:39 PM, Warner Mike - miwarn wrote:
> We came across something that appears to be a bug as opposed to an
> unintended design feature.
Most likely, it is neither a bug nor an unintended feature, but a
documented feature of locale specifications.
>
> I am expecting the output to co
Warner Mike - miwarn wrote:
> We came across something that appears to be a bug as opposed to an
> unintended design feature.
Thank you for the bug report. However what you are seeing is intended
behavior. It isn't something sort has control over. The character
collation sequence is chosen by y
Warner Mike - miwarn writes:
>
> This is a multi-part message in MIME format.
>
> --_=_NextPart_001_01CABF10.3624B78B
> Content-Type: text/plain; charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
Quoted-Unreadable. Minus 10 points.
> I am expecting the output to come out in A
We came across something that appears to be a bug as opposed to an
unintended design feature.
If you consider the following source file (named sort.txt in my
example):
M=L
MIK
M-
M-K
M=
MIK
M-A
miw...@avalanche:/home/miwarn> sort sort.txt
M=
M-
M-A
MIK
MIK
M-K
M=L
miw..
I should have included some information about the system that we are
using:
miw...@avalanche:/home/miwarn> uname -a
Linux avalanche.corp.acxiom.net 2.6.9-89.0.11.ELlargesmp #1 SMP Mon Aug
31 11:05:24 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
miw...@avalanche:/home/miwarn> more /etc/redhat-relea
Hi Padraig,
> From: Chen Guo
> > Any thoughts on the interesting jump at T=8?
> Say we're sorting 32 lines with 8 threads, each thread would get 4 lines to
> sort. If we sort with 7 threads, then 6 threads would get 4 lines, and the
> last
> thread would get 8 to sort. Thus, this last threa
On 2010-03-08 09:57 +0100, Jim Meyering wrote:
> Bob Proulx wrote:
>>
>> Legacy like this?
>>
>> http://dir.gmane.org/gmane.comp.gnu.coreutils.announce
>
> Good point. Forgot about that. And that's the one *I* requested.
> It's just that I don't use that one as much and had
> become inured to
On Sat, 6 Mar 2010 17:46:27 +0800
littlebat wrote:
> Under zh_CN.UTF-8 locale, execute "/bin/echo --help" in the terminal,
> the Simplifield Chinese tranlation of "-n do not output
> the trailing newline" is "-n 不输出为岁的换行", this is a
> translation bug. It should be "-n
> tr -s '[:blank:]' '\t' | cut -f5
And perhaps mention less painful
tr -s \ \\t | cut -f5
and perl -anwle 'print $F[4]'
if the user's input permits such simplification...
Pádraig Brady wrote:
> On 05/03/10 01:31, Pádraig Brady wrote:
>> On 04/03/10 20:05, jida...@jidanni.org wrote:
>>> On (info "(coreutils) cut invocation") please add:
>>> cut has no way to specify a group of blanks as a field demarcator.
>>> If you want that, use perl -a. Also use perl's split if y
Hi Padraig,
> > T=1: 5.10s
> > T=2: 2.87s
> > T=3: 2.71s
> > T=4: 1.75s
> > T=5: 1.66s
> > T=6: 1.65s
> > T=7: 1.67s
> > T=8: 1.31s
>
> Nice results!
>
> A few quick questions:
>
> Any thoughts on the interesting jump at T=8?
Say we're sorting 32 lines with 8 threads, each thread would get 4 l
On 08/03/10 10:14, Kim Hansen wrote:
2010/3/8 Pádraig Brady:
An alternative would be to add a new --kill-wait option
which could be used to specify an additional timeout before a KILL was sent
That would be a general mechanism to terminate "normally" after the timeout
or when SIGTERM etc. is se
On 05/03/10 01:31, Pádraig Brady wrote:
On 04/03/10 20:05, jida...@jidanni.org wrote:
On (info "(coreutils) cut invocation") please add:
cut has no way to specify a group of blanks as a field demarcator.
If you want that, use perl -a. Also use perl's split if you want
regexp demarcators, etc.
If
2010/3/8 Pádraig Brady :
> On 08/03/10 07:17, Jim Meyering wrote:
>>
>> Pádraig Brady wrote:
>>>
>>> Perhaps we could handle all cases with
>>> the equivalent of:
>>>
>>> if (sig==TERM&& user_sig==KILL) {
>>> send(sig); /* give chance to term gracefully */
>>> sleep(1);
>>> send(KILL); /* nu
On 08/03/10 09:11, Chen Guo wrote:
The following runs are conducted on an idle Intel Xeon X5460, 2 dies of 4 cores
each. All values are averages of 20 runs.
T=1: 5.10s
T=2: 2.87s
T=3: 2.71s
T=4: 1.75s
T=5: 1.66s
T=6: 1.65s
T=7: 1.67s
T=8: 1.31s
Nice results!
A few quick questions:
Any thou
On 08/03/10 07:17, Jim Meyering wrote:
Pádraig Brady wrote:
Perhaps we could handle all cases with
the equivalent of:
if (sig==TERM&& user_sig==KILL) {
send(sig); /* give chance to term gracefully */
sleep(1);
send(KILL); /* nuke it from orbit */
}
If the child program's signal-trig
On Mon, 8 Mar 2010, gaosh wrote:
I use the command: date +%Y%m%d%H -d "1990-04-13 12 36 hours"
But I get the result: 1990041501 ! The correct one should be 1990041500.
The result depends on your system's local timezone, which I assume is
set to Asia/Shanghai or equivalent Chinese location. 19
Bob Proulx wrote:
> Jim Meyering wrote:
>> Sven Joachim wrote:
>> > As for the group name, gmane.comp.gnu.core-utils.general seems to be a
>> > reasonable choice.
>>
>> Like Bob, I would have preferred to spell it "coreutils", but I think
>> we're stuck with gmane's existing/legacy spelling.
>
> L
On 2010-03-08, Pádraig Brady wrote:
>
> Also what about the case where a command usually
> behaves normally and exits when it gets a TERM,
> but sometimes it hangs and needs a KILL which
> you specify with timeout. You wouldn't want to
> change the TERM into a KILL in that case.
That is actually
On 2010-03-08 08:59 +0100, Jim Meyering wrote:
> Sven Joachim wrote:
>>
>> I would like to subscribe this new list to Gmane¹ if nobody has done
>
> Thanks! That would be useful.
>
>> this yet. I suppose address encryption² could be turned off (makes it
>> somewhat more convenient to reply) ?
>
>
Hi, Dear Sir,
I use the command: date +%Y%m%d%H -d "1990-04-13 12 36 hours"
But I get the result: 1990041501 ! The correct one should be 1990041500.
date +%Y%m%d%H -d "1990-04-13 12 118799 seconds"
the result is: 1990041500.
But,
date +%Y%m%d%H -d "1990-04-13 12 118800 seconds"
the result is: 1
Jim Meyering wrote:
> Sven Joachim wrote:
> > As for the group name, gmane.comp.gnu.core-utils.general seems to be a
> > reasonable choice.
>
> Like Bob, I would have preferred to spell it "coreutils", but I think
> we're stuck with gmane's existing/legacy spelling.
Legacy like this?
http://di
Sven Joachim wrote:
> On 2010-03-08 07:51 +0100, Jim Meyering wrote:
>> There is a new mailing list: coreut...@gnu.org
>>
>> We will soon hook up a debbugs-based bug tracker to the existing,
>> bug-coreutils list, and it will create a new ticket for each
>> seemingly-new thread.
>>
>> We will then
23 matches
Mail list logo
