43c Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Sun, 22 Aug 2021 11:24:29 -0700
Subject: [PATCH 1/4] doc: spell out stdin, stdout, stderr
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
* doc/coreutils.texi: Spell out words like “stdin” in
English pr
On 8/21/21 3:33 AM, Frans de Boer wrote:
So, I guess chroot is to blame?
Seems unlikely that it'd be a coreutils bug. Possibly you simply have
the wrong type of executable installed as /newroot/usr/sbin/chroot.
If it is a coreutils bug, please give complete steps to let others
reproduce
On 8/20/21 10:40 AM, L A Walsh wrote:
I wanted it just to work
So use 'stat -c "%s %n"'. That works just fine. 'stat' is a good tool
for this job, and there's no need for yet another 'ls' option for this
rare use case.
On 8/20/21 12:02 AM, L A Walsh wrote:
When I use "-b" in du (equivalent to '--apparent-size --block-size=1)
Previously in this thread you asked for "allocated space for a file on a
device", which is why I was talking about that number.
Now you're asking for apparent size, which is a
On 8/17/21 4:03 PM, L A Walsh wrote:
However you want to phrase it, with:
--block-size=SIZE
I want to have 'ls'
'scale sizes by SIZE before printing them'
But that's what --block-size does.
Perhaps your request would be more clear if you gave a specific example
of what you want
On 8/17/21 4:48 PM, softwarebugreports via GNU coreutils Bug Reports wrote:
Thank you for the help! I tried using 8002ca7b56acb46b42eeac4a343e112a8ee283cf
and the latest commits from master
You can't combine the latest Coreutils master commit with old Gnulib
commits like
On 8/17/21 3:24 AM, L A Walsh wrote:
On 2021/08/15 21:36, Paul Eggert wrote:
On 8/15/21 9:26 PM, L A Walsh wrote:
I don't want to display the allocated size on the current device,
but the size that would be allocated on a device with block-size=1-byte.
There's no practical way for 'ls
On 8/15/21 9:26 PM, L A Walsh wrote:
I don't want to display the allocated size on the current device,
but the size that would be allocated on a device with block-size=1-byte.
There's no practical way for 'ls' to calculate that, as the kernel
doesn't reveal that information.
Thanks for reporting the bug. I installed the attached patch to fix it.
>From af4711d5dc15f0c014bfd9c92f4eadedb89f732f Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Sun, 15 Aug 2021 21:29:38 -0700
Subject: [PATCH] chmod: fix use of uninitialized var if -v
Problem reported by Michael Deber
On 8/15/21 4:13 PM, L A Walsh wrote:
Hmm... for libc.so, ls -l shows 253 bytes
for -s, it shows '4' and w/block-size=1, it shows
4096...
Right. That is, those numbers look right.
Simon, this looks like some sort of minor buffering problem in 'basenc
--base64', since plain 'base64' works correctly. Is this something you
have time to look into?
https://bugs.gnu.org/49741
you proposed in that it prefers fstat to stat, as fstat should
be a bit faster and should avoid some unlikely races (there are many
more races, but one fix at a time).
>From 48f59e058b4347172496bede193ade9fbf94d58e Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Wed, 11 Aug 2021 11:16:05 -0
On 8/10/21 11:56 PM, L A Walsh wrote:
Perhaps the '-s' option in ls could pay attention to
the user-specified block-size?
Doesn't it already do that?
$ ls -s libc.so
12192 libc.so
$ ls -s --block-size=1 libc.so
12484608 libc.so
me into (2), I suppose
From dd6591b20e0841e5aecaa082bac1f959a5e18f9c Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Wed, 28 Jul 2021 11:26:48 -0700
Subject: [PATCH 1/2] doc: improve ls documentation
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
thought it better to avoid unnecessary syscalls while I was at it.
The second patch does the real work.
>From 9e4a6101f239b8168144078edd04843dea4dc69f Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Tue, 27 Jul 2021 14:27:00 -0700
Subject: [PATCH 1/2] ls: compute defaults more lazily
MIME-Vers
On 7/26/21 12:52 PM, Bernhard Voelker wrote:
The following options don't work well with --null, because they output other,
additional information or transform/escape the file names:
...
-l use a long listing format
I don't see a problem with -l, as --null can be a
).
From 3753c706b7ccd756db955e850175b79f22911d57 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Sat, 17 Jul 2021 15:07:29 -0500
Subject: [PATCH 1/7] env: fix usage typo
* src/env.c (usage): Fix pluralization typo.
---
src/env.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src
On 7/25/21 7:43 AM, Pádraig Brady wrote:
I would use the more consistent option for this though, i.e.:
-z, --zero end each output line with NUL, not newline
That's a different option, no? My proposal was something that would
affect every program using --quoting-style,
On 7/24/21 10:48 AM, Vito Caputo wrote:
Couldn't we make
-0 and any aliases shorthand for a new --format=WORD where WORD is
names0 or something. That way it's automatically mutually exclusive
with the other formats?
It would make sense to invent a new --quoting-style='literal0' option
(by
On 7/4/21 7:35 AM, Glenn Golden wrote:
You probably want to specify --count-links if you want hardlinked files
(like your example k and l) to be considered by du as separate files:
Yes, that's right. Closing the bug report.
On 7/2/21 4:19 PM, Pádraig Brady wrote:
we might be able to improve things.
For example, using strxfrm() + strcmp() to minimize processing.
I tried that long ago, and it was waaayyy slower than strcoll in the
typical case. glibc strxfrm is not at all optimized.
Which is fine, since strxfrm
On 6/30/21 10:07 AM, He Jingxuan wrote:
bug1: basenc
command: cat basenc1.stdin | basenec --z -
relevant error message: ../src/basenc.c:635:25: runtime error: left shift of
128 by 24 places cannot be represented in type ‘int'
bug2: basenc
command: cat basenc2.stdin | basenc --z - -d
relevant
On 6/24/21 8:50 AM, Paul Eggert wrote:
inotify_init can return 1025 even if called first thing, so we also need
to dup2 the result of early inotify_init down to 3 (or whatever), or at
least to check that it's less than 1024. Choosing 3 is a tricky
business, since it's not clear what fds the C
On 6/24/21 11:49 PM, Erik Auerswald wrote:
$ shuf -i 2-0 ; echo %exit code $?
shuf: invalid input range: ‘2-0’
%exit code 1
$ shuf -i 1-0 ; echo %exit code $?
%exit code 0
This looks inconsistent and possibly not exactly as intended.
It's exactly what I intended and
On 6/24/21 4:46 PM, F8ER F8ER wrote:
For example, `shuf -i 101-100 -n 1` returns nothing with the exit code
= 0 (unexpected).
Actually, it's the expected behavior. It's the same behavior as 'shuf -n
1 it means "output at most 1 line".
On 6/24/21 9:43 AM, Manson Thomas wrote:
So I've restarted my mac, and then uptime was returning correct
values... (after restart, and after latest BigSur update)
That's a relief. Thanks for confirming, and closing the bug report.
On 6/24/21 1:26 AM, Manson Thomas wrote:
$ sudo dtruss /usr/bin/uptime
dtrace: system integrity protection is on, some features will not be available
dtrace: failed to execute /usr/bin/uptime: (os/kern) failure
Can you copy /usr/bin/uptime to /tmp/uptime and then dtruss /tmp/uptime?
On 6/24/21 7:50 AM, Pádraig Brady wrote:
We should be able to inotify_init() earlier in the process to avoid this
issue.
inotify_init can return 1025 even if called first thing, so we also need
to dup2 the result of early inotify_init down to 3 (or whatever), or at
least to check that it's
On 6/23/21 10:03 AM, Manson Thomas wrote:
Can you provide some dtrace command you want me to run ?
I've got dtrace on my machine, but I don't know how to use it.
You're ahead of me, as I don't have dtrace (I don't use macOS). :-)
I believe you can run "dtruss /usr/bin/uptime". You may need
On 6/23/21 8:39 AM, Manson Thomas wrote:
$ /tmp/coreutils/bin/uptime
17:21:21 up 18801 days 14:37, 3 users, load average: 2.37, 2.68, 2.67
The native uptime command from OSx seems to work :
$ /usr/bin/uptime
17:28 up 37 days, 7:43, 3 users, load averages: 2.71 2.44 2.50
Thanks
Thanks for writing that patch. One minor note:
On 6/20/21 7:21 AM, Pádraig Brady wrote:
+(to_uchar (mod_char) << CHAR_BIT)
+ + to_uchar (fmt_char),
Neither mod_char nor fmt_char can be negative (this is guaranteed by the
To get the effect you want, set LC_ALL="C" in your environment. See:
https://www.gnu.org/software/coreutils/manual/html_node/sort-invocation.html#FOOT2
Coreutils mistakenly did not list xstrndup as a module
that it depends on directly. When the latest Gnulib removed
the dirname module's dependency on xstrndup, this mistake
caused coreutils to not build. Since all of Coreutils's
uses of xstrndup know the string length, xmemdup0 is a better
match
The stat output is confusing in other ways. For example:
507-day $ ls -ld .; stat . | grep Device
drwxr-xr-x 4 eggert eggert 12288 May 5 14:48 .
Device: 10300h/66304d Inode: 70388429Links: 4
508-day $ ls -ld /dev/ptp0; stat /dev/ptp0 | grep Device
crw--- 1 root root 246, 0 Jun 3
On 6/5/21 10:42 PM, Zygo Blaxell wrote:
If cp -a implements the inode attribute propagation (or inheritance), then
only users of cp -a are impacted. They are more likely to be aware that
they may be creating new files with reduced-integrity storage attributes.
True, although I think this
On 5/27/21 8:15 AM, Pádraig Brady wrote:
I'm thinking rather than add yet another *sum util,
we might go the route of a single utility with
an option to select which algorithm to use.
+1. This has long been something I wanted.
We could simply overload 'cksum'
On 5/24/21 12:04 PM, Jalim Singh wrote:
Can you please have some suggestions?
Surely this is a problem with the GCC instructions (or with your
particular installation), and it's not a problem with sha256sum itself.
So I suggest reporting the problem to the GCC maintainers, not to the
On 5/11/21 3:17 AM, Thomas Güttinger wrote:
The date command inverts the sign if TZ is set with Etc/GMT.
That's a feature, not a bug. The Etc zones are documented to use the
opposite sign, to be consistent with POSIX settings like TZ='<+05>-5'.
$ date -u; TZ='<+05>-5' date; TZ=Etc/GMT-5
That one's not a real bug. 'install' is exiting, rather than calling
'free' a couple of times just before exiting; calling 'free' would
simply chew up runtime resources for no reason other than to pacify
AddressSanitizer. So I'll close this particular bug report.
Most memory leaks found by
Thanks for reporting the problem. I installed the attached to fix it.
>From aaa0f003303ab90778b6b426cd9e5a1f1d137ffc Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Sat, 1 May 2021 15:19:16 -0700
Subject: [PATCH] touch: fix wrong diagnostic (Bug#48106)
MIME-Version: 1.0
Content-Type: text/pl
lem with a fresh build from scratch, please
investigate why gnulib-tool isn't setting up that link for you
From 1c97d9e2af40003a8ad872fb7f31d4e616f52532 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Mon, 26 Apr 2021 18:02:16 -0700
Subject: [PATCH 1/3] build: update gnulib submodule to latest
* src/cspli
Thanks, I installed that into Savannah master coreutils.
As I wrote you privately last month, the coreutils maintainers (who are
not me) are pretty busy. The proposed change in bug#47883 would be
incompatible with longstanding tradition and would almost certainly
break some existing scripts running on GNU/Linux. This is not something
to do lightly.
On 4/18/21 10:46 AM, Peter van Dijk wrote:
While the manual (but not the manpage) mentions the data loss, I think it would
be great if sort did not have this problem at all, and I think the OpenGroup
text also says it should not have this problem.
I don't know of any 'sort' implementation
On 3/26/21 3:21 PM, Paul Eggert wrote:
The -S code could use some more fixes in this area too - it can
probably still dump core on platforms like the Hurd that don't limit
exec arg size - but one thing at a time.
I fixed the (unlikely) bugs I found in this area by installing the attached
rom 6c4efdc0f51c8e253f16da2ec60cdf647bec3c06 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Fri, 26 Mar 2021 14:00:37 -0700
Subject: [PATCH] doc: document env fix
* NEWS, doc/coreutils.texi (env invocation): Document recent change.
---
NEWS | 3 +++
doc/coreutils.texi | 2 ++
2 fi
Thanks for the bug report. I installed the attached to fix it and am
closing the report.
>From 6dd466eda6fa3f1f7d2a9474ec926ccd2ede98e9 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Fri, 26 Mar 2021 13:49:49 -0700
Subject: [PATCH] env: fix address violation with '\v' in -S
Problem repor
On 3/26/21 1:12 PM, Pádraig Brady wrote:
I'll fix it up.
I've got a fix. My goodness, that part of the code is messy.
On 3/25/21 11:16 AM, Paul Eggert wrote:
I'd prefer it to use IF_LINT (as in the earlier
change), as that makes it cleaner since it's just one line of useless
code, not three.
Installed as attached, and closing the bug report. Thanks again.
>From d3749c46056ddeb1314f35b1644f52179d7a3502
On 3/25/21 9:33 AM, Kamil Dudka wrote:
How does it differ from the following change, which you did not block?
Thanks for reminding me of the earlier exchange. On second thought I
guess it's OK, though I'd prefer it to use IF_LINT (as in the earlier
change), as that makes it cleaner since
Thanks, I installed that. I then changed "free(" to "free (" as per GNU
style.
On 3/25/21 9:08 AM, Kamil Dudka wrote:
Wasn't that exactly what -Dlint was for when we discussed it the last time?
Sorry, don't recall the last time. This is a borderline area, admittedly.
On 3/25/21 3:57 AM, Kamil Dudka wrote:
+#ifdef lint
+ free(hostname);
+#endif
Let's not do this one. The program is about to exit so there's no need
to free, and any static-checking tool that complains about a missing
'free' here is issuing a false alarm. On this particular issue it's
On 3/25/21 6:49 AM, L A Walsh wrote:
If languages such as python and perl can document their usage
in manpages, certainly gnu could be as helpful.
You must be joking. Python and Perl are not fully documented in
manpages. Most free-software projects treat manpages the way the Gnu
project
On 3/23/21 4:22 AM, Luís via GNU coreutils Bug Reports wrote:
In a reinstallation of Linux Mint 20 ( based on the ubuntu 20 focal fossa
), I found that the cat command, supported by the Coreutils package
(8.30-ubuntu2) is no longer working.
Please send a bug report to the Linux Mint
On 3/22/21 4:19 PM, Bernhard Voelker wrote:
BTW: what about a syntax-check rule to ensure we don't forget
to sync files physically copied into 'coreutils.git',
something (not much tested) like the following?
I'll let Jim weigh in on that. Maybe it'd be better for 'bootstrap' to
do the
Today I updated Coreutils to current Gnulib, and noticed that
gnulib-tool warned that Gnulib's 'diacrit' module is obsolete. So I
removed Coreutils's use of 'diacrit', as the only use was something
obsolete in 'ptx'[1].
Does anyone else use 'diacrit'? If not, I suppose we can remove it from
On 3/18/21 8:38 AM, Eric Blake wrote:
POSIX requires 'pr -p' to support paging (although it incorrectly stated
that it waits for \r, and is being fixed to wait for \n instead):
https://austingroupbugs.net/view.php?id=1433
During discussion of the behavior of -p today, the Austin Group was
On 3/11/21 8:53 PM, L A Walsh wrote:
Why are those suffixes listed as valid under the program 'usage'
and manpage, when they are automatically disallowed?
They are valid if your computer has wide-enough integers. As far as I
know no platform supports Y and only one or two supports Z, but the
On 3/10/21 2:50 PM, L A Walsh wrote:
You are using a local 8-bit encoding, whereas everyone else was
using UTF-8. Your mailer re-encoded their messages into one
of the 8-bit western encodings, whereas most people use UTF-8
these days, so while their original messages with accents came
through
On 3/9/21 6:03 PM, L A Walsh wrote:
Thanks for the update and appreciate your diligence...
You're welcome. Closing the bug report.
On 3/9/21 4:58 AM, Philippe Bénézech via GNU coreutils Bug Reports wrote:
df displays G instead of GM as unit size for Gigabytes in power of 1000
(but the value is correct)
$ df -BGB /home
Sys. de fichiers blocs de 1GB Utilisé Disponible Uti% Monté sur
/dev/mapper/ssd2 421GB 355GB
On 3/8/21 6:29 PM, L A Walsh wrote:
Warning, '-f' assuming '-r' was intended
I don't think that'd be helpful, given that -f now has a well-defined
and common meaning that doesn't agree with what you remember, and that
in 4.2BSD (circa 1983) -f meant something quite different from -r and
the
On 3/8/21 5:50 PM, L A Walsh wrote:
Data loss shown in original bug submission. As mentioned/documented
it was use of:
'touch -f '
Sure, but what was the context of that command? Was it part of a shell
script? What was the script for? Can we see a copy? That sort of thing.
I don't know
On 3/8/21 3:27 PM, L A Walsh wrote:
gnu accepts but ignores the previously active '-f'(from) switch
GNU "touch -f" has always been a no-op and has never meant "from" as far
as I know - though I admit I looked back only to 1992. Perhaps you're
thinking of some other "touch" program? If so,
On 2/27/21 1:31 PM, Ronald Knol wrote:
I am looking at "src/cp.c" from coreutils-8.32 and it has command line
options --progress-bar (aka -g).
coreutils-8.32 doesn't have those options. Apparently you have a
modified copy. You can verify this by getting the original from:
On 2/27/21 7:35 AM, Ronald Knol wrote:
This is "cp -argu ". The source tree contains more
than 2TiB worth of data.
I believe the issue is in src/copy.c where (on line 355) an INT is used to
store "cur_size".
int cur_size = g_iTotalWritten + *total_n_read / 1024;
GNU coreutils 'cp'
On 2/15/21 3:07 AM, Grigoriy Sokolik wrote:
But be careful, this is really bad advice: fetching anything without
consistency ad authority validation is really insecure!
Yes, we should instead fix the underlying problem whatever it is (not
sure what it is since that wasn't reported).
On 1/29/21 1:07 AM, Ole Tange wrote:
Could you consider implementing a parallel merge, so I can retire
parsort?
Yes, improving that part of 'sort' performance has been on my long list
of things to do for quite some time. If someone else could take up the
task it'd be done quicker Anyway,
On 1/23/21 1:13 PM, 積丹尼 Dan Jacobson wrote:
And any database command already has
a --limit option these days, and does not rely on a second program to
trim its output because it can't control itself. Indeed, on some remote
connections one would only want to launch one program, not two.
That
On 1/24/21 8:52 AM, Pádraig Brady wrote:
- if (lseek (STDIN_FILENO, start, SEEK_CUR) < 0)
+ if (lseek (STDIN_FILENO, start, SEEK_SET) < 0)
Dumb question: will this handle the case where you're splitting from
stdin and stdin is a seekable file and its initial file offset is nonzero?
On 1/18/21 8:08 AM, Bernhard Voelker wrote:
On 1/17/21 11:18 PM, Paul Eggert wrote:
find DIR -depth -type d -exec rmdir {} +
find(1) can also find empty directories and delete them:
$ find DIR -type d -empty -delete
Thanks, I'd forgotten about that.
I added the attached to the manual
On 1/18/21 2:53 AM, L A Walsh wrote:
Except that 'find DIR -depth -type d -exec rmdir {} +'
is anything but simple and not something anyone outside of
a minority of *nix users would have a clue about how to create, whereas
'rmdir -r DIR' is both direct and simple and
more easily understandable
On 1/16/21 4:29 PM, L A Walsh wrote:
Yes, you could do it some other way, like by using 'find'
That's what I'd do, yes. 'find DIR -depth -type d -exec rmdir {} +'. I
doubt whether it's worth hacking on this at the C level (complicating
the documentation too) when there's such a simple and
Thanks for the bug report. I reproduced the problem and installed the
attached patch to fix it.
>From b8375c422ffe0e018cbb4cad187d1e909195d263 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Fri, 15 Jan 2021 02:57:59 -0800
Subject: [PATCH] mkdir: fix bug when -m's more generous than um
rom: Paul Eggert
Date: Sat, 9 Jan 2021 13:04:40 -0800
Subject: [PATCH] doc: modernize and fix regexp xref
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
* doc/coreutils.texi: Fix regexp cross-reference that had become
out-of-date (Bug#45749). Also, fix s
On 1/6/21 10:56 AM, John Wiersba via GNU coreutils Bug Reports wrote:
$ touch asdf && chmod a-w asdf && rm asdf 2>&1 | catrm: remove write-protected
regular empty file 'asdf'? # should*not* prompt
If the prompt cannot be seen, then it can't be properly answered, so there is
no point
On 1/4/21 7:44 PM, Bela Lubkin wrote:
TLDR: *huge* existing presence of 'iseek' and 'oseek'; most OSes document
them as pure synonyms for 'skip' and 'seek'.
Thanks for doing all that research. It's compelling, and I think your
patch (or something like it) should go in. I'll wait for a bit to
On 1/4/21 3:07 PM, Bernhard Voelker wrote:
I previously encountered a `dd` implementation which also accepted
'oseek=N' and 'iseek=N', which I found far more natural and easy to
remember.
What 'dd' implementation was this specifically?
Solaris dd has iseek and oseek. However, they are not
Thanks for your bug report. I installed the attached patch; although it
doesn't use the exact wording you proposed, I hope it works well enough.
>From 3ee0e25426a513c5da891ce6a370abed156a3b83 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Tue, 15 Dec 2020 11:52:19 -0800
Subject: [PATCH]
On 12/7/20 11:38 AM, Robert S. Kissel wrote:
If you could possibly direct me to the maintainers of the pre-compiled
Windoze port (I'm certain that I downloaded it from the gnu.org
Web-site)
Sure about that? I'm not aware of any. At any rate, whereever you downloaded it
from should have
On 12/6/20 8:23 PM, Robert S. Kissel wrote:
I'm pretty sure this is a bug in the Windoze port of head and tail,
You should have better luck writing directly to the people who prepared that
port, as they don't hang out on this mailing list and we largely don't worry
about MS-Windows.
into this right now.
Is there an SELinux crew at Red Hat that can look at coreutils as a sanity
check?
From 6ac67d13567f4ab10722c612d3ef05d0f2ad80ed Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Mon, 23 Nov 2020 00:52:00 -0800
Subject: [PATCH] maint: propagate errno better in selinux.c
MIME-Version: 1.0
On 11/22/20 10:59 AM, Bernhard Voelker wrote:
selinux.c:257 has a superfluous semicolon after a jump label,
and a strange indentation:
The semicolon is required by the C standard, which does not allow a label before
a declaration. Emacs indented it that way.
On 11/22/20 6:27 AM, Bernhard Voelker wrote:
This is caught by a syntax-check rule as well.
Fixed with the attached patch - as well as 2 other sc failures.
Thanks for fixing that. The tabs got introduced because I edited mv.c with an
unusual Emacs configuration, which I'll try to remember to
Thanks for reporting your recipe for working around all these problems. I've
installed patches for the problems into coreutils and gnulib and am closing the
bug report.
On 11/21/20 3:45 PM, Chris Elvidge wrote:
git commit -m 'build: update gnulib submodule to latest' gnulib 2>&1 | tee -a
| 5 +
lib/parse-datetime.y | 3 ++-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/ChangeLog b/ChangeLog
index de92d102e..229945e86 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,10 @@
2020-11-21 Paul Eggert
+ parse-datetime: fix printf format typo
+ * lib/parse-d
On 11/21/20 5:17 AM, Pádraig Brady wrote:
The info in https://bugs.gnu.org/44739 must be incorrect,
and we've two counter checks to it now.
Yes, that sounds right. Closing that bug report.
test of all this stuff).
From 25f1b02d49a7117a3df502aa4f45e0dec0fc81a0 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Sat, 21 Nov 2020 12:59:09 -0800
Subject: [PATCH 1/3] build: update gnulib submodule to latest
---
gnulib | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On 11/17/20 5:32 AM, Brian J. Murrell wrote:
> [previous line repeated 4 times]
uniq -c already does something like that, though it outputs "5" instead of "4".
Not sure it's worth gussying up 'uniq' to provide exactly the functionality
requested, as output reformatting is easy enough to do
On 11/16/20 10:58 AM, Christina Palka via GNU coreutils Bug Reports wrote:
I got the following error when attempting to install GraphClust2 using
Docker on Mac.
tail: unrecognized file system type 0x794c7630 for
‘/home/galaxy/logs/uwsgi.log’. please report this to bug-coreut...@gnu.or
Thanks
On 11/11/20 3:24 PM, Jan Schaumann wrote:
$ ls -la dir
ls: cannot access dir/.: Permission denied
ls: cannot access dir/..: Permission denied
ls: cannot access dir/file: Permission denied
total 0
d? ? ? ? ?? .
d? ? ? ? ?? ..
-? ? ? ? ??
One way to attack the problem is (1) use only one-liners for option help, and
(2) not worry about indentation so much (either in English or in German) as the
excess indenting doesn't help readability enough to justify the translation
hassle. To do that, I propose changes like the attached for
options are sneaking in from the environment.
>From c1babd86ac26aa718c78c41f05b271c8df6fcf5a Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Mon, 19 Oct 2020 10:47:32 -0700
Subject: [PATCH] build: update gnulib submodule to latest
* gl/lib/randperm.c, src/cp-hash.c, src/ls.c, src/sort.c,
On 10/6/20 4:24 AM, Martin Fido wrote:
I have version 8.25:
Seems to have been fixed by coreutils 8.30:
$ TZ='Australia/Sydney' date -d '2020-10-04T02:00:00Z'
Sun 04 Oct 2020 01:00:00 PM AEDT
On 9/27/20 8:58 PM, Amit Rao wrote:
There's a limit? My first attempt didn't use a wildcard; i attempted to delete
a directory.
'rm dir' fails because 'rm' by default leaves directories alone.
My second attempt was rm -rf dir/*
If "dir" has too many files that will fail due to shell
On 9/27/20 1:00 PM, Amit Rao wrote:
rm /path/*
does not delete files if there are a lot (say 2000) of them in a single
directory
What does the command do instead?
There is a limit as to how many arguments you can pass to 'rm'. If that's what
you ran into, it's a problem with your kernel or
On 9/18/20 4:15 PM, Philip Rowlands wrote:
$ mkdir /tmp/abc
$ cd /tmp/abc
$ rmdir /tmp/abc
$ ls
What happened:
no output, successful exit status
What was expected:
no output, unsuccessful exit status
POSIX says that the rmdir command is supposed to behave like the rmdir syscall.
For the
On 9/14/20 6:31 PM, Cameron Nemo via GNU coreutils Bug Reports wrote:
It seems like relying on the /proc link is not ideal,
and a bug is being hidden by such behavior.
Is there any chance that this can be resolved?
It really should be fixed in the Linux kernel: it needs a proper way to
On 9/1/20 3:30 PM, Karl Berry wrote:
I was on centos7.
(I don't observe your problem on my Fedora 31 box, for example).
Maybe there is hope for a future centos, then.
Maybe. Or it could be a filesystem or mounting issue. My filesystem was ext4
mounted rw,relatime,seclabel, for what
401 - 500 of 3456 matches
Mail list logo
