tags 19376 wontfix
close 19376
stop
(triaging old bugs)
As explained in https://bugs.gnu.org/19377#18 ,
Leaving backup files scattered is undesired.
Closing this as "wontfix".
regards,
- assaf
tags 7829 fixed
close 7829
stop
(triaging old bugs)
On 12/01/11 06:58 AM, Eric Blake wrote:
Ouch - coreutils' printf is also affected:
$ /usr/bin/printf %\'.2f\\n 999.9998 99.9998 100
1000.00
,000,000.00
1,000,000.00
At least printf(1) already uses the xprintf-posix module, so
close 9339
stop
With no further comments in 7 years, I'm closing this item.
-assaf
tags 19374 fixed
close 19374
stop
(triaging old bugs)
This has been fixed in the following commits:
https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=70d8d0f874d11990be48b7b6b70c2c274000b3da
close 13737
stop
(triaging old bugs)
On 18/02/13 06:29 PM, Paul Eggert wrote:
On 02/18/2013 01:44 PM, anatoly techtonik wrote:
"-h" is already a well matured practice to be
implemented
'-h' means something other than "help" for
many common GNU commands: ls, touch, sort, bash, etc.
If we got
tags 18395 notabug
close 18395
stop
(triaging old bugs)
Hello,
On 03/09/14 07:32 AM, macetw wrote:
I expect the shred utility to notice that it's about to operate on a mounted
device, but it gave no such indication.
It seems your email "fell between the cracks" and not replied to in many
close 10446
stop
(triaging old bugs)
Hello,
On 07/01/12 02:29 PM, Jan Girke wrote:
It would be very bold if you make complete video how to's for all the
command line tools and the different CLI's.
For example somebody from the core utils group showed me how to sort
coloumns on the standard
tags 18798 moreinfo
close 18798
stop
(triaging old bugs)
On 23/10/14 12:17 PM, 積丹尼 Dan Jacobson wrote:
"BP" == Bob Proulx writes:
BP> What would you say there instead of or in addition to the above?
I don't really know the best words. I'll leave that to the Pro(ulx)s :-)
With no further
close 10010
stop
(triaging old bugs)
Hello,
On 10/11/11 10:00 AM, Bob Proulx wrote:
severity 10010 wishlist
tags 10010 + confirmed
Michael Lenz wrote:
Aaand I was unable to su to root, due to an "invalid password",
which was strange..
That does seem less than friendly and seems like it
tags 18949 fixed
close 18949
stop
(triaging old bugs)
Hello,
Philippe Rassek wrote:
when running for example seq 1 0 10 it will go into an endless loop.
Imho the 2nd parameter (Increment Statement) should be checked for >
0 (greater then 0) before executing.
It seems your email "fell between
severity 18292 wishlist
tags 18292 wontfix
close 18292
stop
(triaging old bugs)
Hello,
On 18/08/14 02:58 AM, NTENTOS STAVROS wrote:
After running into a problem with differentiating line endings (a bug
with sort, you can follow up my previous e-mail if more details are
needed), I purpose an
tags 18186 moreinfo
close 18186
stop
(triaging old bugs)
On 08/08/14 07:14 AM, Bernhard Voelker wrote:
On 08/08/2014 06:52 AM, James Simmons, President & CEO wrote:
Each file has 1 line with no newline. concatenation should NOT have a
newline.
That is the point of concatenation.
As you
tags 14592 moreinfo
close 14592
stop
(triaging old bugs)
On 11/06/13 06:02 PM, Jared Still wrote:
On Tue, Jun 11, 2013 at 4:59 PM, Pádraig Brady wrote:
I doubt dd is at issue here.
[...]
Is the corruption always 37,533,700 bytes in?
Thanks for the input.
Good question about the
tags 14545 fixed
close 14545
stop
(triaging old bugs)
This was fixed in:
https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=17bbf6ce44eb543a95695fa9d2cbd70fb52c6f42
Marking as "fixed" and closing.
-assaf
tags 14525 notabug
close 14525
stop
(triaging old bugs)
On 26/11/13 08:53 AM, Pádraig Brady wrote:
Doc update attached.
With the update pushed, I'm closing this bug.
https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=17bce8c63e9e0f85b48ca62b63413ce9102af5c1
regards,
- assaf
close 14456
stop
(triaging old bugs)
Hello,
On 23/05/13 02:39 PM, camion_spam-debr...@yahoo.fr wrote:
stat (GNU coreutils) 8.5
the format string length is counted in bytes and not in characters so that the
presence of variable length characters causes misalignment
In the following example
tags 14327 moreinfo
retitle 14327 sort: random hangs executing coreutils 8.21
close 14327
stop
(triaging old bugs)
Hello,
On 05/05/13 12:08 AM, Chen Guo wrote:
[...]
I confirmed this in the disassembly as well to rule out the unlikely
possibility this was the result of some compiler
tags 14275 fixed
close 14275
stop
(triaging old bugs)
On 26/04/13 07:37 AM, Pádraig Brady wrote:
On 04/26/2013 02:02 PM, Cojocaru Alexandru wrote:
Hi,
a while ago I've sent a patch. Could it be applied now?
You can find it here:
tags 14253 fixed
close 14253
stop
(triaging old bugs)
5 years later, coreutils and gnulib-tests are built fine
(most of the time...).
Closing.
-assaf
tags 14246 fixed
close 14246
stop
(triaging old bugs)
In coreutils version 8.24 (released 2015) 'tee' gained
the '--output-error=MODE' option, enabling SIGPIPE handling.
I'm marking this as "fixed" and closing.
regards,
- assaf
tags 14174 moreinfo
close 14174
thanks
(triaging old bugs)
On 11/04/13 04:00 AM, Pádraig Brady wrote:
[...]
So tee is spending time in read() waiting for data from stdin,
and this doesn't happen when writing to file.
So I can only conclude that sqlci is doing something weird with pipes.
Is it
tags 8017 moreinfo
close 8017
stop
(triaging old bugs)
On 11/02/11 08:12 PM, Paul Eggert wrote:
That's a weird one. What type is time_t on that platform,
exactly? Signed or unsigned? 32- or 64-bit?
That test is depending on undefined behavior at the C level,
since it assumes signed integer
tags 7523 moreinfo notabug
close 7523
stop
(triaging old bugs)
With no further comments and no improvement suggestions
in 8 years, I'm closing this bug.
-assaf
tags 13911 moreinfo
close 13911
stop
(triaging old bugs)
On 10/03/13 04:35 PM, Bernhard Voelker wrote:
I suspect you're on NFS, and for some reason, the cleanup fails.
The reason could be that the tail process didn't exit yet.
Does the following additional 'wait' help?
With no further
tags 13765 fixed
retitle 13765 build: HP-NonStop fix
close 13765
stop
(triaging old bugs)
On 19/02/13 02:08 AM, Joachim Schmitz wrote:
In an attempt to port coreutils 8.21 to HP-NonStop I stumbled accross a couple
problems, here are my fixes to them:
Here another file needs to get adjusted
tags 13555 notabug
close 13555
stop
(triaging old bugs)
Hello,
> Paul Eggert wrote:
>
>> Marcel Böhme wrote:
>>> $old/printf "%hi\n" 0x
>>> -1
>>> $printf "%hi\n" 0x
>>> 65535
>>
>> None of these length modifiers are specified by POSIX,
>> so we're talking about what it's more useful
close 13516
stop
(triaging old bugS)
Hello,
On 03/02/13 10:33 PM, Paul Eggert wrote:
On 02/01/2013 05:40 PM, Global Odey wrote:
I'm afraid I'm still puzzled. Still, the patch improves things, since it fixes
what appears to be a serious bug [...]
>
tags 13371 fixed
close 13371
stop
(triaging old bugs)
Hello,
On 06/01/13 04:09 PM, Karl Berry wrote:
Since there's no special benefit to using @acronym{GNU} or @sc{gnu} over
just plain "GNU", it's merely about typographic preferences, my
suggestion was that it was better to avoid the whole
tags 13360 fixed
close 13360
stop
(triaging old bugs)
Hello,
On 06/01/13 05:48 AM, Pádraig Brady wrote:
On 01/04/2013 11:39 PM, Karl Berry wrote:
He replaced @acronym. @sc should go too.
[...]
Pushed with those adjustments.
Only one @sc left in the manual, and I assume it is
tags 13354 moreinfo
close 13354
stop
(triaging old bugs)
Hello,
On 04/01/13 08:48 AM, Jason Bucata wrote:
On Fri, Jan 04, 2013 at 11:01:50AM +, P�draig Brady wrote:
On 01/04/2013 04:07 AM, Jason Bucata wrote:
To get it ideal, we'd need a priority queue implementation here, maybe a
heap
tags 13216 fixed
close 13216
stop
(triaging old bugs)
Hello,
On 17/12/12 06:33 PM, jida...@jidanni.org wrote:
OK indeed
"print the first K bytes of each file"
would mean something like "print the first FEW kilobytes of each file,"
In 2015, head's help screen changed to "--bytes=[-]NUM".
Thank you for your gentle and quick reply.
I am sorry to have misinterpreted parameter names (feel a little stupid
too).
Best Regards.
--
Vittorio Beggi
PHX di Beggi Vittorio
via Cirenaica, 6
35141 Padova PD
Tel/Fax: 049 8756276
Mobile: 340 4871253
mailto: vittorio.be...@gmail.com
32 matches
Mail list logo