On 7/22/11 12:32 PM, Ralph Corderoy wrote:
> Hi Jim,
>
>>> On 07/20/2011 07:34 AM, Ralph Corderoy wrote:
BTW, the code for the built-in printf has a bug. For negative
field-widths it negates a negative integer without checking it
will fit. E.g. on this 64-bit machine
On 7/22/11 10:38 AM, Ralph Corderoy wrote:
>> OK, well for %b and %q bash's built-in printf calls it's own
>> printstr() and that does do things like `fw = -fw' without checking if
>> fw was already the largest negative.
>
> On a related note, I can't interrupt this, e.g. Ctrl-C.
>
> printf '
odd.harry.mannsv...@benteler-alu.com wrote:
> I have tried to use the command cp combining the -a and the -u options.
> I had to stop the copying process midways and restarted it again, and to my
> suprice the diskusage at the destination was 10 -20 % larger than the
> diskusage at the source and m
Hi,
I am running a RHEL 6 and noticed that when using wc -m that the resulting
number is wrong. for example echo "A" | wc -m yield 2 instead of 1. Why is
this? Thanks PAUL>
tag 9166 invalid
thanks
On 07/24/2011 03:58 PM, Paul Ingerson wrote:
for example echo "A" | wc -m yield 2 instead of 1. Why is this?
Thanks for the report; however, this is not a bug. In your example,
echo "A" really did output two characters: A and newline. Try:
echo A | od -tx1z
to s
On 25/07/11 12:42, Jim Meyering wrote:
> odd.harry.mannsv...@benteler-alu.com wrote:
>> I have tried to use the command cp combining the -a and the -u options.
>> I had to stop the copying process midways and restarted it again, and to my
>> suprice the diskusage at the destination was 10 -20 % lar
Pádraig Brady wrote:
> On 25/07/11 12:42, Jim Meyering wrote:
>> odd.harry.mannsv...@benteler-alu.com wrote:
>>> I have tried to use the command cp combining the -a and the -u options.
>>> I had to stop the copying process midways and restarted it again, and to my
>>> suprice the diskusage at the d
Actually I'm wondering now whether the new code
should be unconditionally replacing the dest?
What if the dest is a separate newer file?
I.E. I think the following amended test should pass?
Also what about backups if the separate file is older?
diff --git a/tests/cp/preserve-link b/tests/cp/preser
Hi,
I'm seeing the following strange behavior:
$ umask
0002
$ rm -rf /tmp/src /tmp/dst
$ mkdir -m775 /tmp/src /tmp/src/foo
$ mkdir -m700 /tmp/dst /tmp/dst/foo
$ ls -ld /tmp/dst/foo
drwx-- 2 eric eric 4096 Jul 25 13:40 /tmp/dst/foo
$ cp -r /tmp/src/. /tmp/dst/
$ ls -ld /tmp/dst/foo
drwx-w
On 07/25/11 14:21, Eric Blake wrote:
> This violates the style guide in HACKING; it should either be:
True, but it's consistent with the style that's already used
in that file, near line 954. Perhaps the style should
be changed consistently, as a separate patch.
On 25/07/11 17:26, Pádraig Brady wrote:
> Actually I'm wondering now whether the new code
> should be unconditionally replacing the dest?
> What if the dest is a separate newer file?
> I.E. I think the following amended test should pass?
> Also what about backups if the separate file is older?
Wel
11 matches
Mail list logo