Hi All,
We found a bug in the `head' program of coreutils 8.20:
Invoking `head -c -P' or `head -c -E' will cause memory exhaustion.
However, smaller units (e.g., b, K, M) work fine; bigger units (e.g., Z, Y)
fail properly
(by outputing "number of bytes is so large that it is not representable").
Paul Eggert wrote, On 01/22/2013 03:21 PM:
> On 01/22/13 11:22, Assaf Gordon wrote:
>> 3. Running with 'sudo', 'rm' doesn't fail:
>> $ sudo dtruss $D/rm -r $D/a $D/b 2>/tmp/rm_trace.txt
>
> You need a sudo inside dtruss, to, right?
> Something like this
>
>sudo dtruss sudo -u $USER $D/rm
On 01/22/13 11:22, Assaf Gordon wrote:
> 3. Running with 'sudo', 'rm' doesn't fail:
> $ sudo dtruss $D/rm -r $D/a $D/b 2>/tmp/rm_trace.txt
You need a sudo inside dtruss, to, right?
Something like this
sudo dtruss sudo -u $USER $D/rm -r $D/a $D/b 2>/tmp/rm_trace.txt
Paul Eggert wrote, On 01/22/2013 02:01 AM:
> Thanks, to help debug that can you please try the following
> shell commands? The idea is to run the newly-built "rm" in
> a directory that is not readable.
>
> cd coreutils-8.20/src
> D=$(pwd)
> mkdir -p a/1 b c d/2 e/3
> cd c
> chmod u=x,go= .
> ktra
On 01/22/2013 02:24 PM, Pádraig Brady wrote:
> Yes I was wondering that myself.
>
> Though I suppose that `seq 0 0 1` prints endlessly,
> means that it's consistent that as long as start <= end
> and step == 0, then start is printed endlessly.
Yes, from a mathematical point of view, seq is right.
On 01/22/2013 12:28 PM, Bernhard Voelker wrote:
On 01/22/2013 01:17 PM, Pádraig Brady wrote:
Updated patch attached.
That one is looking good ... but while we're at it:
Anyone tried this, i.e. a Zero as INCREMENT?
$ seq 1 0 2
This is equal to `yes 0`. Well, this is probably a (not
docume
On 01/22/2013 12:17 PM, Pádraig Brady wrote:
On 01/22/2013 11:23 AM, Pádraig Brady wrote:
On 01/22/2013 10:43 AM, Marcel Böhme wrote:
Dear all,
There is another bug that sneaked into the speed patch of seq on 13.09.12:
560 if (all_digits_p (argv[optind])
561 && (n_args == 1 || all_di
On 01/22/2013 01:17 PM, Pádraig Brady wrote:
> Updated patch attached.
That one is looking good ... but while we're at it:
Anyone tried this, i.e. a Zero as INCREMENT?
$ seq 1 0 2
This is equal to `yes 0`. Well, this is probably a (not
documented) feature, but in the following examples, the "
On 01/22/2013 12:23 PM, Pádraig Brady wrote:
> On 01/22/2013 10:43 AM, Marcel Böhme wrote:
>>
>> Dear all,
>>
>> There is another bug that sneaked into the speed patch of seq on 13.09.12:
>>
>> 560 if (all_digits_p (argv[optind])
>> 561 && (n_args == 1 || all_digits_p (argv[optind + 1]))
>>
On 01/22/2013 11:23 AM, Pádraig Brady wrote:
On 01/22/2013 10:43 AM, Marcel Böhme wrote:
Dear all,
There is another bug that sneaked into the speed patch of seq on 13.09.12:
560 if (all_digits_p (argv[optind])
561 && (n_args == 1 || all_digits_p (argv[optind + 1]))
562 && (n_arg
On 01/22/2013 10:43 AM, Marcel Böhme wrote:
Dear all,
There is another bug that sneaked into the speed patch of seq on 13.09.12:
560 if (all_digits_p (argv[optind])
561 && (n_args == 1 || all_digits_p (argv[optind + 1]))
562 && (n_args < 3 || STREQ ("1", argv[optind + 2]))
563
Dear all,
There is another bug that sneaked into the speed patch of seq on 13.09.12:
560 if (all_digits_p (argv[optind])
561 && (n_args == 1 || all_digits_p (argv[optind + 1]))
562 && (n_args < 3 || STREQ ("1", argv[optind + 2]))
563 && !equal_width && !format_str && strlen (
12 matches
Mail list logo
