bug#74653: closed (Re: bug#74653: tail --follow=name doesn't exit when using inotify and the file is moved)

Thank you for a quick follow up and prompt fix of this issue!

bug#47151: closed (Re: bug#47151: cp --recursive funky behaviour)

On 2/21/22 10:49, Tomas wrote: I found this, I am not sure whether it's the right specs. https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/ Yes, or more precisely for 'cp': https://pubs.opengroup.org/onlinepubs/9699919799/utilities/cp.html "2) f) The files in the directory sourc

bug#47151: closed (Re: bug#47151: cp --recursive funky behaviour)

i?bug=47151 GNU Bug Tracking System Contact help-debb...@gnu.org with problems = Forwarded message ========= Subject: Re: bug#47151: cp --recursive funky behaviour From: "Paul Eggert" Date: Mon, 21 Feb 2022 01:54:02 -0800 To: "Tom

bug#53145: 回覆: Re: bug#53145: "cut" can't segment Chinese characters correctly?

zendas@Backup-Server:/tmp$ echo "你好啊" | cut -c 1-3 | od -b 000 344 275 240 012 004 zendas@Backup-Server:/tmp$ echo "你好啊" | cut -c 1 | od -b 000 344 012 002 zendas@Backup-Server:/tmp$ echo "你好啊" | cut -b 1 | od -b 000 344 012 002 zendas@Backup-Server:/tmp$ echo "你好啊" | cut -n

bug#46422: [PATCH] Re: bug#46422: 'pr' screws up tabstops in multicolumn outpt?

On 15/02/2021 07:19, Erik Auerswald wrote: On Sun, Feb 14, 2021 at 11:04:21PM +, Pádraig Brady wrote: On 14/02/2021 19:22, Erik Auerswald wrote: May I ask you to test the new patch (v4) as well? This version looks good. I'll probably apply this after a little more local testing. Pushed

bug#46422: [PATCH] Re: bug#46422: 'pr' screws up tabstops in multicolumn outpt?

On Sun, Feb 14, 2021 at 11:04:21PM +, Pádraig Brady wrote: > On 14/02/2021 19:22, Erik Auerswald wrote: > >May I ask you to test the new patch (v4) as well? > > This version looks good. > I'll probably apply this after a little more local testing. Thanks!

bug#46422: [PATCH] Re: bug#46422: 'pr' screws up tabstops in multicolumn outpt?

On 14/02/2021 19:22, Erik Auerswald wrote: May I ask you to test the new patch (v4) as well? This version looks good. I'll probably apply this after a little more local testing. Thanks to both of you! Pádraig

bug#46422: [PATCH] Re: bug#46422: 'pr' screws up tabstops in multicolumn outpt?

On Sun, 2021-02-14 at 20:22 +0100, Erik Auerswald wrote: > Hi, > > On 13.02.21 21:28, Leonard Janis Robert König wrote: > > On Sat, 2021-02-13 at 21:15 +0100, Erik Auerswald wrote: > > > On 13.02.21 19:29, Leonard Janis Robert König wrote: > > > > [...] > > > > That being said, I don't see this ex

bug#46422: [PATCH] Re: bug#46422: 'pr' screws up tabstops in multicolumn outpt?

Hi, On 13.02.21 21:28, Leonard Janis Robert König wrote: On Sat, 2021-02-13 at 21:15 +0100, Erik Auerswald wrote: On 13.02.21 19:29, Leonard Janis Robert König wrote: [...] That being said, I don't see this exact distinction reflected in the code, so perhaps I just misunderstood. Disabling "

bug#46422: [PATCH] Re: bug#46422: 'pr' screws up tabstops in multicolumn outpt?

On Sat, 2021-02-13 at 21:15 +0100, Erik Auerswald wrote: > Hi, > > On 13.02.21 19:29, Leonard Janis Robert König wrote: > > > > first:  Thank you very much for the work, I really owe you one! > > You're welcome. :-) > > > On Sat, 2021-02-13 at 17:58 +0100, Erik Auerswald wrote: > > > On 13.02.2

bug#46422: [PATCH] Re: bug#46422: 'pr' screws up tabstops in multicolumn outpt?

Hi, On 13.02.21 19:29, Leonard Janis Robert König wrote: first: Thank you very much for the work, I really owe you one! You're welcome. :-) On Sat, 2021-02-13 at 17:58 +0100, Erik Auerswald wrote: On 13.02.21 15:17, Erik Auerswald wrote: On 11.02.21 20:20, Erik Auerswald wrote: On Thu,

bug#46422: [PATCH] Re: bug#46422: 'pr' screws up tabstops in multicolumn outpt?

Hi, first: Thank you very much for the work, I really owe you one! On Sat, 2021-02-13 at 17:58 +0100, Erik Auerswald wrote: > On 13.02.21 15:17, Erik Auerswald wrote: > > On 11.02.21 20:20, Erik Auerswald wrote: > > > On Thu, Feb 11, 2021 at 06:09:28PM +0100, Leonard Janis Robert > > > König >

bug#46422: [PATCH] Re: bug#46422: 'pr' screws up tabstops in multicolumn outpt?

Hi, On 13.02.21 15:17, Erik Auerswald wrote: On 11.02.21 20:20, Erik Auerswald wrote: On Thu, Feb 11, 2021 at 06:09:28PM +0100, Leonard Janis Robert König wrote: On Thu, 2021-02-11 at 16:45 +0100, Erik Auerswald wrote: On Thu, Feb 11, 2021 at 04:12:54PM +0100, Leonard Janis Robert König wrote

bug#46422: [PATCH] Re: bug#46422: 'pr' screws up tabstops in multicolumn outpt?

On 11.02.21 20:20, Erik Auerswald wrote: On Thu, Feb 11, 2021 at 06:09:28PM +0100, Leonard Janis Robert König wrote: On Thu, 2021-02-11 at 16:45 +0100, Erik Auerswald wrote: On Thu, Feb 11, 2021 at 04:12:54PM +0100, Leonard Janis Robert König wrote: On Thu, 2021-02-11 at 13:00 +0100, Erik Auer

bug#42440: �ظ���bug#42440: closed (Re: bug#42440: bug with rm)

ok, --  -- ??: "42440" http://debbugs.gnu.org/cg

bug#36831: Enhance directory move. (was Re: bug#36831: enhance 'directory not empty' message)

Hello, On 2019-08-02 9:56 p.m., L A Walsh wrote: On 2019/08/02 19:47, Assaf Gordon wrote: Can new merging features be added to 'mv'? yes. But it seems to me these would be better suited for 'higher level' programs (e.g. a GUI file manager). --- But neither the person who posted the ori

bug#36831: Enhance directory move. (was Re: bug#36831: enhance 'directory not empty' message)

On 2019/08/02 19:47, Assaf Gordon wrote: > Can new merging features be added to 'mv'? yes. > But it seems to me these would be better suited for 'higher level' > programs (e.g. a GUI file manager). --- But neither the person who posted the original bug on this nor I are using a GUI, we a

bug#36831: Enhance directory move. (was Re: bug#36831: enhance 'directory not empty' message)

Hello, On Fri, Aug 02, 2019 at 02:41:31AM -0700, L A Walsh wrote: > On 2019/07/28 23:28, Assaf Gordon wrote: > > > > > > $ mkdir A B B/A > > $ touch A/bar B/A/foo > > $ mv A B > > mv: cannot move 'A' to 'B/A': Directory not empty > > > > And the reason (as you've found out) is that

bug#36831: Enhance directory move. (was Re: bug#36831: enhance 'directory not empty' message)

On 2019/07/28 23:28, Assaf Gordon wrote: > > > $ mkdir A B B/A > $ touch A/bar B/A/foo > $ mv A B > mv: cannot move 'A' to 'B/A': Directory not empty > > And the reason (as you've found out) is that the target directory 'B/A' > is not empty (has the 'foo' file in it). > Had this bee

bug#35289: closed (Re: bug#35289: date+%-Y -d "- N years" errors when N > 111)

On Tue, Apr 16, 2019 at 1:37 PM Assaf Gordon wrote: > Thank you both for testing. > > So, to summarize: > whenever "inv-year" fails - it is a problem with glibc on your > setup, *not* a problem in coreutils' date(1) program. > > If there is a setup where "inv-year" succeeds but date(1) still fail

bug#35289: closed (Re: bug#35289: date+%-Y -d "- N years" errors when N > 111)

Hello, On 2019-04-15 5:10 p.m., O. Emmerson wrote: For me it gives: $ ./inv-year time() = 1555369320 localtime() = 2019-04-16 00:02:00 (mday=16 wday=2, isdst=1) struct tm (after adjustment) = 0009-04-16 00:02:00 (mday=16 wday=2, isds

bug#35289: closed (Re: bug#35289: date+%-Y -d "- N years" errors when N > 111)

C de-Avillez wrote: So: a pristine 19.04 runs it. My laptop (which is my work machine, full of other packages & programs), does not. You might try running 'strace' on pristine 19.04 and on your laptop, and see if you can spot the difference in system calls. Possibly you have some stuff on you

bug#35289: closed (Re: bug#35289: date+%-Y -d "- N years" errors when N > 111)

It has to be something messing/interacting with coreutils/date on 19.04 (and probably on Tumbleweed). I created a new container with 19.04, and then: * apt build-dep coreutils * apt install rsync wget git * git clone git://git.sv.gnu.org/coreutils * cd coreutils * export FORCE_UNSAFE_CONFIGURE=1 #

bug#35289: closed (Re: bug#35289: date+%-Y -d "- N years" errors when N > 111)

On 15/04/2019 21:55, Assaf Gordon wrote: To see if this is glibc issue, or perhaps an gnulib/mktime_z wrapper issue, can you (and/or others) try the attached C program? It calls time(2)+localtime(3)+mktime(3) to emulate the date adjustment. Because the adjustment is to year 9 (about 1961 years

bug#35289: closed (Re: bug#35289: date+%-Y -d "- N years" errors when N > 111)

cerdea@piatam:~/Downloads$ gcc -o inv-year inv-year.c cerdea@piatam:~/Downloads$ ./inv-year time() = 1555368087 localtime() = 2019-04-15 17:41:27 (mday=15 wday=1, isdst=1) struct tm (after adjustment) = 0009-04-15 17:41:27 (mday=15 wday=1, isdst=1) inv-yea

bug#35289: closed (Re: bug#35289: date+%-Y -d "- N years" errors when N > 111)

Thanks Bernhard, On 2019-04-15 2:14 p.m., Bernhard Voelker wrote: I can easily reproduce here on my regular openSUSE:Tumbleweed from latest git: $ src/date --debug '+%-Y' -d '- 2010 years' [] date: error: adding relative date resulted in an invalid date: '(Y-M-D) 0009-04-15 22:10:3

bug#35289: closed (Re: bug#35289: date+%-Y -d "- N years" errors when N > 111)

On 4/15/19 9:41 PM, Assaf Gordon wrote: > A good starting point is adding the "--debug" option to date(1) > and examining its output. Hi Assaf, I can easily reproduce here on my regular openSUSE:Tumbleweed from latest git: $ src/date --debug '+%-Y' -d '- 2010 years' date: parsed relative par

bug#35289: closed (Re: bug#35289: date+%-Y -d "- N years" errors when N > 111)

Hello, On 2019-04-15 11:55 a.m., C de-Avillez wrote: 19.04: It is worth noting that Ubuntu 19.04 has not been officially released yet, so you are testing on a development branch (or a release-candidate, or a special built infrastructure as hinted by your path). cerdea@piatam:/data/buildd/cor

bug#35289: closed (Re: bug#35289: date+%-Y -d "- N years" errors when N > 111)

I have ran a few tests on Ubuntu 16.04, 18.04, 18.10, and 19.04 (all X86_64): 16.04: root@u1604:~# date +%-Y -d '- 2010 years' 9 root@u1604:~# date --version date (GNU coreutils) 8.25 Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later

bug#35289: closed (Re: bug#35289: date+%-Y -d "- N years" errors when N > 111)

$ file /bin/date /bin/date: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=26fa7f6c43c354d8c5647ebf946255a2b8e3c53d, stripped

bug#35289: closed (Re: bug#35289: date+%-Y -d "- N years" errors when N > 111)

I have downloaded and compiled 8.31 from source to see if it makes any difference and have gotten the same error.

bug#35289: closed (Re: bug#35289: date+%-Y -d "- N years" errors when N > 111)

On 15/04/2019 17:02, GNU bug Tracking System wrote: It works for me with coreutils 8.31 on RHEL 7 x86-64: $ date +%-Y -d "- 2010 years" 9 Most likely you are running on a 32-bit machine, and dates in the year 9 cannot be represented in a 32-bit timestamp. So a simple fix would be for you to swi

bug#34199: closed (Re: bug#34199: Small bug in cp (for win64))

Hi, Bob ... thanks so much for the info! (very entertaining!) 🤓 You were right ... I had installed the newer version of Coreutils from cygwin and that works better (but still has some NTFS-related bugs, I think). New version: C:\temp\x\x>cp --version cp (GNU coreutils) 8.26 Packaged by Cygwin (8

bug#34199: closed (Re: bug#34199: Small bug in cp (for win64))

Chris Kalish wrote: > Hmmm ... not sure of the distribution, but the help file pointed me at this > address: > C:\> cp --version > cp (GNU coreutils) 5.3.0 I always hate it when I am on your side of things and upstream says this to me. But here I am on the other side and going to say almost exac

bug#34199: closed (Re: bug#34199: Small bug in cp (for win64))

ong with your original report. >> If you require more details, please reply to 34...@debbugs.gnu.org. >> >> -- >> 34199: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=34199 >> GNU Bug Tracking System >> Contact help-debb...@gnu.org with problems >> >> &g

bug#34199: closed (Re: bug#34199: Small bug in cp (for win64))

- Forwarded message -- > From: Eric Blake > To: Chris Kalish , 34199-d...@debbugs.gnu.org > Cc: > Bcc: > Date: Fri, 25 Jan 2019 14:33:57 -0600 > Subject: Re: bug#34199: Small bug in cp (for win64) > tag 34199 notabug > thanks > > On 1/25/19 11:14 AM, Chr

bug#31554: acknowledged by developer (Re: bug#31554: Fwd: Re: Potential bug in md5sum)

Hello Bill, On 2018-11-18 2:37 p.m., Riedy, Bill wrote: The wording is vague, could you please clarify which of the following are true: 1) That you recognize this as a bug and it is going to be fixed 2) That you recognize this as a bug but it will NOT be fixed 3) Some other scenario that I c

bug#31554: acknowledged by developer (Re: bug#31554: Fwd: Re: Potential bug in md5sum)

The wording is vague, could you please clarify which of the following are true: 1) That you recognize this as a bug and it is going to be fixed 2) That you recognize this as a bug but it will NOT be fixed 3) Some other scenario that I can't think of, but you may have. On 10/30/2018 5:05 AM, G

bug#29939: 回复: Re: bug#29939: HELP:enter a "ls"command, then the os connection will closed

tags 29939 moreinfo close 29939 stop (triaging old bugs) On 2018-01-08 8:22 a.m., Bernhard Voelker wrote: On 01/04/2018 01:58 AM, lil...@chinaunicom.cn wrote: $ type ls ls is aliased to `ls $LS_OPTIONS' It was a bit hard to find a an old SLES-11.1 ... Hmm, is your LS_OPTIONS set to something

bug#21349: acknowledged by developer (Re: bug#21349: who shows no users nowadays on Debian)

(Today on Debian I see $ who jidanni pts/02018-10-25 06:26 (:0) So maybe this is fixed.)

bug#14971: acknowledged by developer (Re: bug#14971: split man page table mushed)

積丹尼 Dan Jacobson writes: > Say, can we get the final information just from this email next time, > just like in Debian. Where one doesn't need to click on the link to see > how the bug was solved. Well, we plan to merge with Debian's debbugs sources. This should improve also messages like this.

bug#14971: acknowledged by developer (Re: bug#14971: split man page table mushed)

Say, can we get the final information just from this email next time, just like in Debian. Where one doesn't need to click on the link to see how the bug was solved. > "GbTS" == GNU bug Tracking System writes: GbTS> This is an automatic notification regarding your bug report GbTS> #14971: sp

bug#9394: Fwd: Re: bug#9394: coreutils-8.7 - few test cases failed

tags 9394 moreinfo close 9394 stop (triaging old bugs) Hello, On 13/09/11 04:58 AM, Toralf Förster wrote: Toralf Förster wrote at 12:57:39 Jim Meyering wrote at 11:49:26 Are there any test failures with *unmodified* coreutils-8.13 on your system? No. Therefore I should file a bug against

bug#29069: Fwd: Fwd: Re: bug#29069: info coreutils file permissions: improvements/bug-report

until now, no one responded to my patch proposal neither encorporated it as I see. why not? kalle Weitergeleitete Nachricht Betreff: Fwd: Re: bug#29069: info coreutils file permissions: improvements/bug-report Datum: Wed, 31 Jan 2018 00:55:31 +0100 Von: kalle An: bug

bug#30661: closed (Re: bug#30661: sort)

reopen 30661 retitle 30661 RFE: Add way for sort to handle hex numbers tag 30661 -notabug thanks On 03/01/2018 05:29 PM, James Bunke wrote: $ echo -e "170\n11" | sort -n echo -e is not portable; printf is better. 11 170 $ echo -e "AA\nB" | sort -n AA B $ echo -e "0xAA\n0xB" | sort -n 0xAA 0x

bug#29069: Fwd: Re: bug#29069: info coreutils file permissions: improvements/bug-report

I have a patch for chapter 27.3, coreutils texinfo-document. greetings, kalle From b250dcdaba02083a0174d9157c655f0dbb586ef6 Mon Sep 17 00:00:00 2001 From: kalle Date: Wed, 3 Jan 2018 20:56:07 +0100 Subject: [PATCH] changed presentation in 'File permissions' in 'numeric modes' I described the nu

bug#29939: 回复: Re: bug#29939: HELP:enter a "ls"command, then the os connection will closed

On 01/04/2018 01:58 AM, lil...@chinaunicom.cn wrote: > $ type ls > ls is aliased to `ls $LS_OPTIONS' It was a bit hard to find a an old SLES-11.1 ... Hmm, is your LS_OPTIONS set to something strange? What if you remove the alias? Have a nice day, Berny

bug#29939: 回复: Re: bug#29939: HELP:enter a "ls"command, then the os connection will closed

oelker 发送时间： 2018-01-03 21:11 收件人： lil...@chinaunicom.cn; 29...@debbugs.gnu.org 主题： Re: bug#29939: HELP:enter a "ls"command, then the os connection will closed On 01/02/2018 07:25 AM, lil...@chinaunicom.cn wrote: > When I enter a "ls " command at the directory "/r

bug#28775: 回复: Re: bug#28775: bug report

[ please don't top-post on technical lists] On 10/11/2017 04:09 AM, cheng...@zhongan.com wrote: > On 2017-10-10 20:36, Bernhard Voelker wrote: >> This is an 'overlayfs' file system - this issue is already fixed since >> coreutils-8.25 >> (and now we're at 8.28). > > It's the latest version, but

bug#27942: closed (Re: bug#27942: Bug regarding "touch" command)

System > Contact help-debb...@gnu.org with problems > > > -- Forwarded message -- > From: Paul Eggert > To: pavan kumar yalavarthi , > 27942-d...@debbugs.gnu.org > Cc: > Bcc: > Date: Fri, 4 Aug 2017 00:16:23 -0700 > Subject: Re: bug#27942: Bug regarding "touch&qu

bug#26081: closed (Re: bug#26081: --date=STRING error that started midnight 3/12)

It is a great FAQ and yes I see it covers this. Now I understand it would not be able to tell me the 2AM for the day we are skipping it. What threw me off was also the fact that 'tomorrow' was a day we did not skip 2AM. So the clocks went forward at 2AM on 3/12. But I was asking for the next

bug#24800: closed (Re: bug#24800: expr 8.25 seems to treat 0 in character class in paren incorrectly)

Hello people. Thank you for explanations, examples and sorry for BCC. While in office, I'm now allowed to use To or CC. -- iida >Your bug report > >#24800: expr 8.25 seems to treat 0 in character class in paren incorrectly > >which was filed against the coreutils package, has been closed.

bug#22686: closed (Re: bug#22686: An empty string marked for translation)

> bug introduced in coreutils-8.24 Already in 8.24? Right, it does happen to my system coreutils (Fedora 23). I assumed it was a new mistake, so I never checked that. (And it shows that gettext does not guard aginst it.) But good to have it fixed either way. :-)

bug#20850: acknowledged by developer (Re: bug#20850: Converting under Linux a by date calculated epochtime back with date, does not return the same data)

On 22/06/15 13:05, Bahn, Ingo wrote: > Hello Pádraig / GNU (coreutils) team, > > I hope you had a good weekend and thank you for the quick reply. I appreciate > that. > > The -u (UTC) option I also attempted before opening the bug with you, but > also got the same different results between Linu

bug#20850: acknowledged by developer (Re: bug#20850: Converting under Linux a by date calculated epochtime back with date, does not return the same data)

date -u -d "1970-01-01Q00:00:00" +"Q":%t%s date -u -d "1970-01-01R00:00:00" +"R":%t%s date -u -d "1970-01-01S00:00:00" +"S":%t%s date -u -d "1970-01-01T00:00:00" +"T":%t%s date -u -d "1970-01-01U00:00:0

bug#19375: closed (Re: bug#19377: bug#19378: [PATCH 3/4] cat, chcon, chgrp, chmod, chown, cp, du, head: support wildcards on OS/2)

Pádraig Brady wrote: > reopen 19377 > stop > > On 19/12/14 01:13, KO Myung-Hun wrote: >> >> GNU bug Tracking System wrote: >>> Your bug report >>> >>> #19377: [PATCH 1/4] doc: add $(EXEEXT) suffix to the executables >>> >>> which was filed against the coreutils package, has been closed. >>> >>>

bug#19375: closed (Re: bug#19377: bug#19378: [PATCH 3/4] cat, chcon, chgrp, chmod, chown, cp, du, head: support wildcards on OS/2)

reopen 19377 stop On 19/12/14 01:13, KO Myung-Hun wrote: > > GNU bug Tracking System wrote: >> Your bug report >> >> #19377: [PATCH 1/4] doc: add $(EXEEXT) suffix to the executables >> >> which was filed against the coreutils package, has been closed. >> >> The explanation is attached below, alon

bug#19375: closed (Re: bug#19377: bug#19378: [PATCH 3/4] cat, chcon, chgrp, chmod, chown, cp, du, head: support wildcards on OS/2)

GNU bug Tracking System wrote: > Your bug report > > #19377: [PATCH 1/4] doc: add $(EXEEXT) suffix to the executables > > which was filed against the coreutils package, has been closed. > > The explanation is attached below, along with your original report. > If you require more details, please

bug#19021: closed (Re: bug#19021: Possible bug in sort)

; -- Forwarded message -- > From: Eric Blake > To: Ben Mendis , 19021-d...@debbugs.gnu.org > Cc: > Date: Tue, 11 Nov 2014 10:39:13 -0700 > Subject: Re: bug#19021: Possible bug in sort > tag 19021 notabug > thanks > > On 11/11/2014 09:39 AM, Ben Mendis wrot

bug#18540: closed (Re: bug#18540: Sorting bug?)

On 09/24/2014 08:59 PM, Paul Eggert wrote: To help the Fedora folks squash it I installed the attached test case upstream. This test succeeds with upstream 'sort' but fails with the Fedora 20 version. FWIW there's now a downstream patch on top of the coreutils-i18n.patch available on the open

bug#18540: closed (Re: bug#18540: Sorting bug?)

On 09/24/2014 10:40 AM, Göran Uddeborg wrote: Drats! I felt so proud after the last paragraph of your first comment! :-) I would like to chime in with thanks for reporting this bug, which is a real howler. To help the Fedora folks squash it I installed the attached test case upstream. This

bug#18540: closed (Re: bug#18540: Sorting bug?)

Drats! I felt so proud after the last paragraph of your first comment! :-) But I've filed https://bugzilla.redhat.com/show_bug.cgi?id=1146185 (I'm also using Fedora).

bug#18273: closed (Re: bug#18273: sort seems to misbehave if both -u and -n or -k are used)

On Fri, Aug 15, 2014 at 02:32:14PM -0600, Eric Blake wrote: > 'info sort' says: > > The '--stable' ('-s') option > disables this "last-resort comparison" so that lines in which all fields > compare equal are left in their original relative order. The '--unique' > ('-u') option also disables the

bug#18273: closed (Re: bug#18273: sort seems to misbehave if both -u and -n or -k are used)

On 08/15/2014 02:22 PM, Lennart Sorensen wrote: > OK I accept that it is correct behaviour. > > The documentation on the other hand is awful in that case. I went and > checked the documentation to try and make sense of what it was doing > before sending the report, and there was nothing there th

bug#18273: closed (Re: bug#18273: sort seems to misbehave if both -u and -n or -k are used)

sen , > 18273-d...@debbugs.gnu.org > Subject: Re: bug#18273: sort seems to misbehave if both -u and -n or -k are > used > > tag 18273 notabug > thanks > > On 08/15/2014 01:30 PM, Lennart Sorensen wrote: > > Here is the case that has me thinking there is a bug (it

bug#17253: Re: bug#17253: date "--date=-x\ days"

hanes wrote: > You got me to the right point with the daylight saving time. All of us were pretty sure that would be the root of the problem. > I really do not thought it is that trivial. > So I am sorry to bother You with this, and disgrace me like that. Please do not worry. We are happy to he

bug#17253: Re: bug#17253: date "--date=-x\ days"

You got me to the right point with the daylight saving time. I really do not thought it is that trivial. So I am sorry to bother You with this, and disgrace me like that. But to answer the Questions: I switched my bios clock two hours forward, but of course it had no effect; so everything is actua

bug#17161: closed (Re: bug#17161: Bug in date arithmetic of date)

Hi, Yes, I've come to the same conclusion (i.e. the numeric value in "+3 days" or "-2 days" being treated as time zone). The 8.5 coreutils I tested on is in a different time zone so it is possible it doesn't exhibit the same behavior because of that, and as such I can't actually tell whether t

bug#17161: closed (Re: bug#17161: Bug in date arithmetic of date)

reopen 17161 thanks On 04/02/2014 02:17 AM, Marc R.J. Brevoort wrote: > Hello, > > As a heads-up, the explanation that this is due to time zone+locale > doesn't make sense: > > mrjb@THE-D-MRJB:~$ date --utc -d "2014-03-11 12:34:56 -1 day" +"%Y-%m-%d > %H:%M:%S" > 2014-03-12 13:34:56 > mrjb@THE-D

bug#17161: closed (Re: bug#17161: Bug in date arithmetic of date)

Hello, As a heads-up, the explanation that this is due to time zone+locale doesn't make sense: mrjb@THE-D-MRJB:~$ date --utc -d "2014-03-11 12:34:56 -1 day" +"%Y-%m-%d %H:%M:%S" 2014-03-12 13:34:56 mrjb@THE-D-MRJB:~$ date --utc -d "2014-03-11 12:34:56 -2 days" +"%Y-%m-%d %H:%M:%S" 2014-03-1

bug#15945: closed (Re: bug#15945: chown: Does now allow setting user and users login group with numerical user ID)

Dear GNU team, But why is not possible for "chown 1001: /tmp/bla" to resolve 1001 to "me" and then do the same than "chown me: /tmp/bla" ? (I guess internally chown will do the reverse lookup (me -> 1001), when performing a "chown me: /tmp/bla") Could you please be so kind to explain the "why no

bug#9987: closed (Re: bug#9987: [PATCH] groups, id: add -0, --null option)

PC!draig Brady wrote: On 09/22/2013 03:08 AM, Linda Walsh wrote: GNU bug Tracking System wrote: Your bug report #9987: RFE: 'groups' command ADD command switches "-0", and "-1" which was filed against the coreutils package, has been closed. The explanation is attached below, along with yo

bug#9987: closed (Re: bug#9987: [PATCH] groups, id: add -0, --null option)

On 09/22/2013 03:08 AM, Linda Walsh wrote: > > > GNU bug Tracking System wrote: >> Your bug report >> >> #9987: RFE: 'groups' command ADD command switches "-0", and "-1" >> >> which was filed against the coreutils package, has been closed. >> >> The explanation is attached below, along with your

bug#9987: closed (Re: bug#9987: [PATCH] groups, id: add -0, --null option)

GNU bug Tracking System wrote: Your bug report #9987: RFE: 'groups' command ADD command switches "-0", and "-1" which was filed against the coreutils package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 9..

bug#15040: closed (Re: bug#15040: comm --check-order doc boost)

Fine, when we produce an erroneous death row list, don't blame me...

bug#13665: closed (Re: bug#13665: Question about the translation of double_to_human)

Thanks!

bug#13243: closed (Re: bug#13243: [PATCH] enhancement: modify md5sum to allow piping)

On 12/21/2012 12:12 AM, Daniel Santos wrote: > On 12/20/2012 11:49 PM, Eric Blake wrote: >> dd if=/dev/sda3 | pbzip2 -c2 | tee >(md5sum > /tmp/sda3.dat.bzip2.md5) | >> netcat 192.168.1.123 45678 > Wow! It was worth writing a patch just to discover the >(list) and > <(list) constructs. I knew abo

bug#13243: closed (Re: bug#13243: [PATCH] enhancement: modify md5sum to allow piping)

On 12/20/2012 04:51 PM, GNU bug Tracking System wrote: Your bug report #13243: [PATCH] enhancement: modify md5sum to allow piping which was filed against the coreutils package, has been closed. The explanation is attached below, along with your original report. If you require more details, ple

bug#12675: closed (Re: bug#12675: find RFE test verb "-inodes")

Subject: Re: bug#12675: find RFE test verb "-inodes" From: Eric Blake Date: Thu, 18 Oct 2012 11:23:03 -0600 To: Linda Walsh To: Linda Walsh CC: 12675-d...@debbugs.gnu.org tag 12675 notabug thanks on each dir...which really slows things down... Sorry, but you'

bug#9086: ls --color: 30% speed-up and case-insensitive suffixes [Re: bug#9086

Pádraig Brady wrote: > On 10/13/2012 03:41 PM, Jim Meyering wrote: >> Pádraig Brady wrote: >> >>> On 10/09/2012 02:32 PM, Jim Meyering wrote: Pádraig Brady wrote: > On 10/09/2012 01:32 PM, Jim Meyering wrote: >> Pádraig Brady wrote: ... >>> So do we now only support suffixes

bug#9086: ls --color: 30% speed-up and case-insensitive suffixes [Re: bug#9086

On 10/13/2012 03:41 PM, Jim Meyering wrote: Pádraig Brady wrote: On 10/09/2012 02:32 PM, Jim Meyering wrote: Pádraig Brady wrote: On 10/09/2012 01:32 PM, Jim Meyering wrote: Pádraig Brady wrote: ... So do we now only support suffixes delimited by '.' ? Previously the delimiter was arbitrar

bug#9086: ls --color: 30% speed-up and case-insensitive suffixes [Re: bug#9086

Pádraig Brady wrote: > On 10/09/2012 02:32 PM, Jim Meyering wrote: >> Pádraig Brady wrote: >>> On 10/09/2012 01:32 PM, Jim Meyering wrote: Pádraig Brady wrote: >> ... > So do we now only support suffixes delimited by '.' ? > Previously the delimiter was arbitrary or optional: > >>

bug#9086: ls --color: 30% speed-up and case-insensitive suffixes [Re: bug#9086

On 10/09/2012 02:32 PM, Jim Meyering wrote: Pádraig Brady wrote: On 10/09/2012 01:32 PM, Jim Meyering wrote: Pádraig Brady wrote: ... So do we now only support suffixes delimited by '.' ? Previously the delimiter was arbitrary or optional: touch star; LS_COLORS="*tar=01;31" /bin/ls --col

bug#9086: ls --color: 30% speed-up and case-insensitive suffixes [Re: bug#9086

Pádraig Brady wrote: > On 10/09/2012 01:32 PM, Jim Meyering wrote: >> Pádraig Brady wrote: ... >>> So do we now only support suffixes delimited by '.' ? >>> Previously the delimiter was arbitrary or optional: >>> >>>touch star; LS_COLORS="*tar=01;31" /bin/ls --color *tar >> >> Good catch. I re

bug#9086: ls --color: 30% speed-up and case-insensitive suffixes [Re: bug#9086

On 10/09/2012 01:32 PM, Jim Meyering wrote: Pádraig Brady wrote: On 10/09/2012 12:52 PM, Jim Meyering wrote:> Eric Blake wrote: On 07/26/2011 02:33 PM, marcel partap wrote: Here's a patch. Adds STRCASEEQ_LEN macro for case insensitive extension matching. #regards/marcel. Your patch would mak

bug#9086: ls --color: 30% speed-up and case-insensitive suffixes [Re: bug#9086

Pádraig Brady wrote: > On 10/09/2012 12:52 PM, Jim Meyering wrote:> Eric Blake wrote: >>> On 07/26/2011 02:33 PM, marcel partap wrote: Here's a patch. Adds STRCASEEQ_LEN macro for case insensitive extension matching. #regards/marcel. >>> >>> Your patch would make the new behavior unc

bug#9086: ls --color: 30% speed-up and case-insensitive suffixes [Re: bug#9086

On 10/09/2012 12:52 PM, Jim Meyering wrote:> Eric Blake wrote: >> On 07/26/2011 02:33 PM, marcel partap wrote: >>> Here's a patch. Adds STRCASEEQ_LEN macro for case insensitive extension >>> matching. >>> #regards/marcel. >> >> Your patch would make the new behavior unconditional. But I like case

bug#9086: ls --color: 30% speed-up and case-insensitive suffixes [Re: bug#9086

Eric Blake wrote: > On 07/26/2011 02:33 PM, marcel partap wrote: >> Here's a patch. Adds STRCASEEQ_LEN macro for case insensitive extension >> matching. >> #regards/marcel. > > Your patch would make the new behavior unconditional. But I like case > sensitivity, and think that case insensitivity sh

bug#12494: closed (Re: bug#12494: 0 exit status even when chmod fails)

Georgiy Treyvus wrote: > On 9/25/12 3:00 AM, GNU bug Tracking System wrote: >> Your bug report >> >> #12494: 0 exit status even when chmod fails ... > Wait. Before you folks put the final nail in the coffin I have three > points/questions: Thanks for replying. That shows that while it was a forego

bug#12494: closed (Re: bug#12494: 0 exit status even when chmod fails)

On 09/25/2012 12:02 PM, Georgiy Treyvus wrote: > On 9/25/12 1:56 PM, Georgiy Treyvus wrote: >> On 9/25/12 3:00 AM, GNU bug Tracking System wrote: >>> Your bug report >>> >>> #12494: 0 exit status even when chmod fails >>> >>> which was filed against the coreutils package, has been closed. >>> >>> T

bug#12494: closed (Re: bug#12494: 0 exit status even when chmod fails)

On 9/25/12 1:56 PM, Georgiy Treyvus wrote: On 9/25/12 3:00 AM, GNU bug Tracking System wrote: Your bug report #12494: 0 exit status even when chmod fails which was filed against the coreutils package, has been closed. The explanation is attached below, along with your original report. If you

bug#12494: closed (Re: bug#12494: 0 exit status even when chmod fails)

On 9/25/12 3:00 AM, GNU bug Tracking System wrote: Your bug report #12494: 0 exit status even when chmod fails which was filed against the coreutils package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to12...@d

bug#9780: sort -u data loss deserves new release ASAP [Re: bug#9780: sort -u...

Jim Meyering wrote: ... > That sort -u can cause data loss is a big deal. > I want to make a release with this fix as soon as possible. > Since I'm making this a mostly-bug-fix release, the du and md5 --tag > changes will have to wait for 8.20. > However, I'll be happy to apply documentation-correc

bug#9780: sort -u data loss deserves new release ASAP [Re: bug#9780: sort -u...

On 08/17/2012 12:00 PM, Jim Meyering wrote: > I want to make a release with this fix as soon as possible. > Since I'm making this a mostly-bug-fix release, the du and md5 --tag > changes will have to wait for 8.20. > However, I'll be happy to apply documentation-correcting changes > if someone woul

bug#9780: sort -u data loss deserves new release ASAP [Re: bug#9780: sort -u...

Jim Meyering wrote: > Jim Meyering wrote: > ... >> In case anyone is chomping at the bit, here's a preliminary patch: >> >> Here's a smaller test case that appears to be host/nproc-independent: >> It should print two lines: 1, then 7. >> Without this patch, it prints only "7". >> >> (yes 7|head

bug#12023: � closed (Re: bug#12023: bug of hostid cmd ?)

.centos.9.i686 >> [lin@centos ~]$ which hostid >> /usr/bin/hostid >> [lin@centos ~]$ ldd /usr/bin/hostid >> linux-gate.so.1 => (0x00dc) >> libc.so.6 => /lib/libc.so.6 (0x00902000) >> /lib/ld-linux.so.2 (0x008dc000) >> [lin@centos ~]$ > > > --

bug#12023: RE��bug#12023: closed (Re: bug#12023: bug of hostid cmd ?)

000) > [lin@centos ~]$ -- ???????? -- ??: "GNU bug Tracking System"; : 2012??7??22??(??) 8:12 ??: " e nQQ "<55079...@qq.com>; : bug#12023: closed (Re: bug#12023: bug of hostid cmd ?) Your bug report #1202

bug#11994: [PATCH] Re: bug#11994: sort(1) doesn't say SEE ALSO uniq(1)

Erik Auerswald wrote: > On Fri, Jul 20, 2012 at 01:54:21AM +0800, jida...@jidanni.org wrote: >> sort(1) doesn't say SEE ALSO uniq(1), and vice versa. > > The small attached patch adds that. ... > Subject: [PATCH] doc: mention uniq(1) in sort(1) man-page and vice versa > > * man/sort.x: Add SEE ALSO

bug#11994: [PATCH] Re: bug#11994: sort(1) doesn't say SEE ALSO uniq(1)

Hi, On Fri, Jul 20, 2012 at 01:54:21AM +0800, jida...@jidanni.org wrote: > sort(1) doesn't say SEE ALSO uniq(1), and vice versa. The small attached patch adds that. Erik -- Golden rule #12: When the comments do not match the code, they probably are both wrong.

bug#11631: closed (Re: bug#11631: Head command does not position file pointer correctly for negative line count)

On Thu, Jun 7, 2012 at 11:15 PM, Eric Blake wrote: > [please don't top-post on technical lists] > > On 06/07/2012 08:37 AM, Anoop Sharma wrote: >> The thought behind the proposed change was that lseek should reflect >> the amount of data that head has actually been able to print. > > But that's no

  1   2   3   4   5   6   7   8   9   10   >