bug#9129: Built-in printf Sits Awkwardly with UDP.

2011-07-25 Thread Chet Ramey
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

bug#9129: Built-in printf Sits Awkwardly with UDP.

2011-07-25 Thread Chet Ramey
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 '

bug#8419: cp -au : New hard links in source becomes new files at destination when using cp -au

2011-07-25 Thread Jim Meyering
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

bug#9166: wc -m that the resulting number is wrong

2011-07-25 Thread Paul Ingerson
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>

bug#9166: wc -m that the resulting number is wrong

2011-07-25 Thread Eric Blake
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

bug#8419: cp -au : New hard links in source becomes new files at destination when using cp -au

2011-07-25 Thread Pádraig Brady
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

bug#8419: cp -au : New hard links in source becomes new files at destination when using cp -au

2011-07-25 Thread Jim Meyering
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

bug#8419: cp -au : New hard links in source becomes new files at destination when using cp -au

2011-07-25 Thread Pádraig Brady
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

bug#9170: [PATCH] cp "restores" permissions it never set

2011-07-25 Thread Eric Lammerts
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

bug#9170: [PATCH] cp "restores" permissions it never set

2011-07-25 Thread Paul Eggert
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.

bug#8419: cp -au : New hard links in source becomes new files at destination when using cp -au

2011-07-25 Thread Pádraig Brady
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