bug#70873: join --return-error-if-any-unmatched-lines

[Pádraig Brady]

On 11/05/2024 10:14, Dan Jacobson wrote:

join should have an option to return an error value in the shell's $?
if any lines are not matched.

Currently the man page doesn't even mention a return value. So it is not
set in stone yet.

Currently one must save -v output in a file then use test -s do detect
if there were any non-matched lines. And then exit one script with
non-zero. Big hassle.

join (GNU coreutils) 9.4


This does seem to have some merit.
Perhaps --check-pairable similar to the existing --check-order option.

cheers,
Pádraig

bug#70873: join --return-error-if-any-unmatched-lines

[Dan Jacobson]

join should have an option to return an error value in the shell's $?
if any lines are not matched.

Currently the man page doesn't even mention a return value. So it is not
set in stone yet.

Currently one must save -v output in a file then use test -s do detect
if there were any non-matched lines. And then exit one script with
non-zero. Big hassle.

join (GNU coreutils) 9.4

bug#70714: realpath no error for unreadable-symlink

[Pádraig Brady]

On 02/05/2024 07:16, Nineteendo INC wrote:

coreutils version: stable 9.5 (bottled)
OS version: macOS 13.6.6 (22G630)

`realpath` doesn’t behave correctly for unreadable symlinks:

wannes@Stefans-iMac ~ % ln -s . src
wannes@Stefans-iMac ~ % grealpath -e src/..
/Users
wannes@Stefans-iMac ~ % chmod -h 000 src
wannes@Stefans-iMac ~ % grealpath -e src/..
/Users/wannes

Expected behaviour:

wannes@Stefans-iMac ~ % grealpath -e src/..
grealpath: src/..: Permission denied


Right, looks like we'll have to cater for EACCES on darwin.
I'll have a look

bug#70714: realpath no error for unreadable-symlink

[Nineteendo INC]

coreutils version: stable 9.5 (bottled)
OS version: macOS 13.6.6 (22G630)

`realpath` doesn’t behave correctly for unreadable symlinks:

wannes@Stefans-iMac ~ % ln -s . src
wannes@Stefans-iMac ~ % grealpath -e src/..
/Users
wannes@Stefans-iMac ~ % chmod -h 000 src
wannes@Stefans-iMac ~ % grealpath -e src/..
/Users/wannes

Expected behaviour:

wannes@Stefans-iMac ~ % grealpath -e src/..
grealpath: src/..: Permission denied

bug#68866: man page description of pwd command has error I guess

[Bernhard Voelker]

tag 68866 notabug
close 68866
stop

On 2/1/24 04:09, Seungchul Lee wrote:

man page description has following line,
"If no option is specified, -P is assumed."
But in my machine, its default behavior seems -L without any option for pwd.


'man pwd' and 'env pwd --help' also tells:

  NOTE: your shell may have its own version of pwd, which usually supersedes
  the version described here.  Please refer to your shell's documentation
  for details about the options it supports.

Are you sure that you are running pwd(1) from GNU coreutils, or that of the 
shell?

  $ pwd# pwd of the shell
  /home/berny/osc

  $ env pwd# pwd of GNU coreutils
  /media/osc

  $ /usr/bin/pwd   # pwd of GNU coreutils
  /media/osc

Have a nice day,
Berny

bug#68866: man page description of pwd command has error I guess

[Seungchul Lee]

Hello,

man page description has following line,
"If no option is specified, -P is assumed."
But in my machine, its default behavior seems -L without any option for pwd.

Sincerely yours,
Lee.

bug#68064: Date addition error with “day Monthname” versus “Monthname day”

[Pádraig Brady]

tag 68064 notabug
close 68064
stop

On 27/12/2023 17:29, Larry Ploetz wrote:

It seems like there might be a problem with date addition when the base
date is specified as “day Monthname” instead of “Monthname day”, where
the offset is being interpreted as an absolute year value. This may be
locale-specific.

 :bin larry$ locale
 LANG="en_US.UTF-8"
 LC_COLLATE="en_US.UTF-8"
 LC_CTYPE="en_US.UTF-8"
 LC_MESSAGES="en_US.UTF-8"
 LC_MONETARY="en_US.UTF-8"
 LC_NUMERIC="en_US.UTF-8"
 LC_TIME="en_US.UTF-8"
 LC_ALL=
 :bin larry$ ./date -d "$(./date -d today +%d\ %b) + 1 day"
 Fri Dec 28 00:00:00 LMT 0001
 :bin larry$ ./date -d "$(./date -d today +%b\ %d) + 1 day"
 Thu Dec 28 00:00:00 CST 2023
 :bin larry$ ./date --version
 date (GNU coreutils) 9.4.97-98d463
 Copyright (C) 2023 Free Software Foundation, Inc.
 License GPLv3+: GNU GPL version 3 or 
later.
 This is free software: you are free to change and redistribute it.
 There is NO WARRANTY, to the extent permitted by law.


This is due to ambiguity in date input formats.
Your case is:

  $ date --debug -d "27 Dec + 1 day"
  date: parsed date part: (Y-M-D) -001-12-27
  date: parsed relative part: +1 day(s)

A slightly adjusted case highlighting the ambiguity:

  $ date --debug -d "27 Dec + 1 week"
  date: parsed date part: (Y-M-D) -001-12-27
  date: parsed relative part: +7 day(s)

So really the solution here is to avoid the ambiguity
by explicitly specifying the year, or more abstractly
specifying "today" rather than a partial date.

Another gotcha highlighted by the --debug option above is:

  date: warning: using midnight as starting time: 00:00:00
  date: starting date/time: '(Y-M-D) 0001-12-27 00:00:00'
  date: warning: when adding relative days, it is recommended to specify noon

Another gotcha is that only English month abbreviations
are supported on input, so your command will fail in other locales.

For a summary of date input issues see:
https://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-date-command-is-not-working-right_002e
https://www.gnu.org/software/coreutils/manual/html_node/Date-input-formats.html#index-date-input-formats

cheers,
Pádraig

bug#68064: Date addition error with “day Monthname” versus “Monthname day”

[Larry Ploetz]

It seems like there might be a problem with date addition when the base 
date is specified as “day Monthname” instead of “Monthname day”, where 
the offset is being interpreted as an absolute year value. This may be 
locale-specific.


   :bin larry$ locale
   LANG="en_US.UTF-8"
   LC_COLLATE="en_US.UTF-8"
   LC_CTYPE="en_US.UTF-8"
   LC_MESSAGES="en_US.UTF-8"
   LC_MONETARY="en_US.UTF-8"
   LC_NUMERIC="en_US.UTF-8"
   LC_TIME="en_US.UTF-8"
   LC_ALL=
   :bin larry$ ./date -d "$(./date -d today +%d\ %b) + 1 day"
   Fri Dec 28 00:00:00 LMT 0001
   :bin larry$ ./date -d "$(./date -d today +%b\ %d) + 1 day"
   Thu Dec 28 00:00:00 CST 2023
   :bin larry$ ./date --version
   date (GNU coreutils) 9.4.97-98d463
   Copyright (C) 2023 Free Software Foundation, Inc.
   License GPLv3+: GNU GPL version 3 or 
later.
   This is free software: you are free to change and redistribute it.
   There is NO WARRANTY, to the extent permitted by law.

   Written by David MacKenzie.

Thanks,
·Larry

bug#65294: [PATCH] maint: Fix compilation error on GNU/Hurd

[Pádraig Brady]

On 14/08/2023 20:02, Bruno Haible wrote:

Compiling a current coreutils on Debian GNU/Hurd from 2022, I get this
compilation error:

   CC   src/copy.o
../src/copy.c: In function 'set_author':
../src/copy.c:984:15: error: 'MACH_PORT_nullptr' undeclared (first use in this 
function); did you mean 'MACH_PORT_NULL'?
   984 |   if (file == MACH_PORT_nullptr)
   |   ^
   |   MACH_PORT_NULL
../src/copy.c:984:15: note: each undeclared identifier is reported only once 
for each function it appears in
make[2]: *** [Makefile:12489: src/copy.o] Error 1

The attached patch fixes it.



Pushed.

thanks,
Pádraig

bug#65294: [PATCH] maint: Fix compilation error on GNU/Hurd

[Bruno Haible]

Compiling a current coreutils on Debian GNU/Hurd from 2022, I get this
compilation error:

  CC   src/copy.o
../src/copy.c: In function 'set_author':
../src/copy.c:984:15: error: 'MACH_PORT_nullptr' undeclared (first use in this 
function); did you mean 'MACH_PORT_NULL'?
  984 |   if (file == MACH_PORT_nullptr)
  |   ^
  |   MACH_PORT_NULL
../src/copy.c:984:15: note: each undeclared identifier is reported only once 
for each function it appears in
make[2]: *** [Makefile:12489: src/copy.o] Error 1

The attached patch fixes it.

>From 2046827462094dde4ac8391865a3edc74e313126 Mon Sep 17 00:00:00 2001
From: Bruno Haible 
Date: Mon, 14 Aug 2023 20:59:41 +0200
Subject: [PATCH] maint: Fix compilation error on GNU/Hurd (regression
 2023-06-29)

* src/copy.c (set_author): Revert change from MACH_PORT_NULL to
MACH_PORT_nullptr.
---
 src/copy.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/copy.c b/src/copy.c
index 90eebf6bc..a4aad06a8 100644
--- a/src/copy.c
+++ b/src/copy.c
@@ -981,7 +981,7 @@ set_author (char const *dst_name, int dest_desc, const struct stat *src_sb)
   file_t file = (dest_desc < 0
  ? file_name_lookup (dst_name, 0, 0)
  : getdport (dest_desc));
-  if (file == MACH_PORT_nullptr)
+  if (file == MACH_PORT_NULL)
 error (0, errno, _("failed to lookup file %s"), quoteaf (dst_name));
   else
 {
-- 
2.34.1

bug#64654: input error handling

[Pádraig Brady]

Just creating a bug to track the recent fixes
to read error handling in various coreutils. I.e.:

https://github.com/coreutils/coreutils/commit/9d333aca4  cksum
https://github.com/coreutils/coreutils/commit/0e62ba282  tsort
https://github.com/coreutils/coreutils/commit/5595673d5  numfmt
https://github.com/coreutils/coreutils/commit/82e1750da  factor

Note tests were added to check read error handling in all utils:
https://github.com/coreutils/coreutils/commit/7ea7c020e
https://github.com/coreutils/coreutils/commit/5e1c5f2d7

cheers,
Pádraig

bug#62497: maybe date -f should generate an error

[Pádraig Brady]

On 28/03/2023 13:42, Pádraig Brady wrote:

On 28/03/2023 09:54, Paul Eggert wrote:

Thanks for reporting that. I installed the attached to fix it.


Looks good thanks.
Also worth the attached test and NEWS,
which I've pushed.


I'm also applying the attached for fix the same issue in dircolors.

cheers,
Pádraig
From a9bd274616a8d2e99736b498e657cda4e6954f3f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?= 
Date: Tue, 28 Mar 2023 14:24:29 +0100
Subject: [PATCH] dircolors: diagnose read errors

* NEWS: Mention the fix.
* src/dircolors.c: Fail upon read error from getline().
* tests/misc/dircolors.sh: Add a new test.
* tests/local.mk: Reference the new test.
---
 NEWS|  4 ++--
 src/dircolors.c |  5 +
 tests/local.mk  |  1 +
 tests/misc/dircolors.sh | 28 
 4 files changed, 36 insertions(+), 2 deletions(-)
 create mode 100755 tests/misc/dircolors.sh

diff --git a/NEWS b/NEWS
index 8f602325c..bade99043 100644
--- a/NEWS
+++ b/NEWS
@@ -10,8 +10,8 @@ GNU coreutils NEWS-*- outline -*-
   more restricted systems like android or containers etc.
   [bug introduced in coreutils-9.2]
 
-  date --file will now diagnose a failure to read the file.
-  Previously it would have silently ignored the failure.
+  date --file and dircolors will now diagnose a failure to read a file.
+  Previously they would have silently ignored the failure.
   [This bug was present in "the beginning".]
 
   md5sum --check again correctly prints the status of each file checked.
diff --git a/src/dircolors.c b/src/dircolors.c
index f95524b67..f43a57db5 100644
--- a/src/dircolors.c
+++ b/src/dircolors.c
@@ -298,6 +298,11 @@ dc_parse_stream (FILE *fp, char const *filename)
 {
   if (getline (_line, _line_size, fp) <= 0)
 {
+  if (ferror (fp))
+{
+  error (0, errno, _("%s: read error"), quotef (filename));
+  ok = false;
+}
   free (input_line);
   break;
 }
diff --git a/tests/local.mk b/tests/local.mk
index c958c138c..a0c024905 100644
--- a/tests/local.mk
+++ b/tests/local.mk
@@ -306,6 +306,7 @@ all_tests =	\
   tests/misc/date-sec.sh			\
   tests/misc/date-tz.sh\
   tests/misc/dircolors.pl			\
+  tests/misc/dircolors.sh			\
   tests/misc/dirname.pl\
   tests/misc/env-null.sh			\
   tests/misc/env-S.pl\
diff --git a/tests/misc/dircolors.sh b/tests/misc/dircolors.sh
new file mode 100755
index 0..9e2ae2890
--- /dev/null
+++ b/tests/misc/dircolors.sh
@@ -0,0 +1,28 @@
+#!/bin/sh
+
+# Copyright (C) 2023 Free Software Foundation, Inc.
+
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see <https://www.gnu.org/licenses/>.
+
+. "${srcdir=.}/tests/init.sh"; path_prepend_ ./src
+print_ver_ dircolors
+
+# Make sure dircolors fails when it can't read input
+# (the current directory in this case)
+if ! cat . >/dev/null; then
+  # can't read() directories
+  returns_ 1 dircolors . || fail=1
+fi
+
+Exit $fail
-- 
2.26.2

bug#62497: maybe date -f should generate an error

[Pádraig Brady]

On 28/03/2023 09:54, Paul Eggert wrote:

Thanks for reporting that. I installed the attached to fix it.


Looks good thanks.
Also worth the attached test and NEWS,
which I've pushed.

cheers,
PádraigFrom a4525de1ef593cb3873eb88caa7279eb32669bda Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?= 
Date: Tue, 28 Mar 2023 13:38:52 +0100
Subject: [PATCH] tests: add a test case for the previous date fix

* NEWS: Also mention this bug fix.
* tests/misc/date-f.sh: Add a new test.
* tests/local.mk: Reference the new test.
---
 NEWS |  4 
 tests/local.mk   |  1 +
 tests/misc/date-f.sh | 29 +
 3 files changed, 34 insertions(+)
 create mode 100755 tests/misc/date-f.sh

diff --git a/NEWS b/NEWS
index 3b0524c22..8f602325c 100644
--- a/NEWS
+++ b/NEWS
@@ -10,6 +10,10 @@ GNU coreutils NEWS-*- outline -*-
   more restricted systems like android or containers etc.
   [bug introduced in coreutils-9.2]
 
+  date --file will now diagnose a failure to read the file.
+  Previously it would have silently ignored the failure.
+  [This bug was present in "the beginning".]
+
   md5sum --check again correctly prints the status of each file checked.
   Previously the status for files was printed as 'OK' once any file had passed.
   This also applies to cksum, sha*sum, and b2sum.
diff --git a/tests/local.mk b/tests/local.mk
index 1e93290d0..c958c138c 100644
--- a/tests/local.mk
+++ b/tests/local.mk
@@ -302,6 +302,7 @@ all_tests =	\
   tests/misc/csplit-io-err.sh			\
   tests/misc/csplit-suppress-matched.pl		\
   tests/misc/date-debug.sh			\
+  tests/misc/date-f.sh\
   tests/misc/date-sec.sh			\
   tests/misc/date-tz.sh\
   tests/misc/dircolors.pl			\
diff --git a/tests/misc/date-f.sh b/tests/misc/date-f.sh
new file mode 100755
index 0..ebbb95652
--- /dev/null
+++ b/tests/misc/date-f.sh
@@ -0,0 +1,29 @@
+#!/bin/sh
+# Verify -f processing
+
+# Copyright (C) 2023 Free Software Foundation, Inc.
+
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see .
+
+. "${srcdir=.}/tests/init.sh"; path_prepend_ ./src
+print_ver_ date
+
+# Make sure date fails when it can't read input
+# (the current directory in this case)
+if ! cat . >/dev/null; then
+  # can't read() directories
+  returns_ 1 date -f . || fail=1
+fi
+
+Exit $fail
-- 
2.26.2

bug#62497: maybe date -f should generate an error

[Paul Eggert]

Thanks for reporting that. I installed the attached to fix it.From 9c5e542fd190a14431092e3b6cb45d18fe95f26f Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Tue, 28 Mar 2023 01:52:43 -0700
Subject: [PATCH] date: diagnose -f read errors

* src/date.c (batch_convert): Diagnose read errors, fixing Bug#62497.
---
 src/date.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/date.c b/src/date.c
index 0f2012761..bc4cc0ce9 100644
--- a/src/date.c
+++ b/src/date.c
@@ -368,7 +368,9 @@ batch_convert (char const *input_filename, char const *format,
   ssize_t line_length = getline (, , in_stream);
   if (line_length < 0)
 {
-  /* FIXME: detect/handle error here.  */
+  if (ferror (in_stream))
+die (EXIT_FAILURE, errno, _("%s: read error"),
+ quotef (input_filename));
   break;
 }
 
-- 
2.37.2

bug#62497: maybe date -f should generate an error

[Sylvestre Ledru]

Hello

The usual case is:

$ echo "2023-03-27 08:30:00" > dates.txt
$ echo "2023-04-01 12:00:00" >> dates.txt

$ /usr/bin/date -f dates.txt
Mon Mar 27 08:30:00 CEST 2023
Sat Apr 1 12:00:00 CEST 2023

If done on a non existing file, we get:

$ date -f non-existing
/usr/bin/date: non-existing: No such file or directory

Maybe it should do the same on a directory:

 $ /usr/bin/date -f /
doesn't show anything and return 0

Cheers,
Sylvestre

bug#61706: info page of cp contains error

[Pádraig Brady]

On 22/02/2023 13:28, Martin Castillo wrote:

Hi,

the info page of cp says

Plain ‘--reflink’ is equivalent to ‘--reflink=when’.

but probably means

Plain ‘--reflink’ is equivalent to ‘--reflink=always’.

Martin Castillo


Already fixed in https://github.com/coreutils/coreutils/commit/c7920f2b1

Marking this as done.

cheers,
Pádraig

bug#61706: info page of cp contains error

[Martin Castillo]

Hi,

the info page of cp says

  Plain ‘--reflink’ is equivalent to ‘--reflink=when’.

but probably means

  Plain ‘--reflink’ is equivalent to ‘--reflink=always’.

Martin Castillo

bug#61467: Don't assume short/long options for error messages

[Dan Jacobson]

$ sort --human-numeric-sort -nr
sort: options '-hn' are incompatible

Say instead:
sort: options --human-numeric-sort (-h), and --numeric-sort (-n), are 
incompatible.

Else some projects might be delayed by days, as some people need to
email other people to ask...

"Can't blame me. That's not what I typed. I typed -nr, not -hn. Sue me."

bug#60030: Small error in date command

[Pádraig Brady]

tag 60030 notabug
close 60030
stop

On 13/12/2022 02:50, Malin Freeborn wrote:

Hi bug-team,

There's a small error in the date man page. If you search for `%F`
you'll notice the date is summarized as so:

%F full date; like %+4Y-%m-%d

The example shows the `%` sign before the `+`.


This was intentional. '+' is a flag in this context as per:
https://github.com/coreutils/coreutils/commit/2ab2f7a42

cheers,
Pádraig

bug#60030: Small error in date command

[Malin Freeborn]

Hi bug-team,

There's a small error in the date man page. If you search for `%F`
you'll notice the date is summarized as so:

%F full date; like %+4Y-%m-%d

The example shows the `%` sign before the `+`.

Best,
 - Malin

bug#59901: Valgrind Memory Error

[Pádraig Brady]

tag 59901 notabug
close 59901
stop

On 08/12/2022 03:44, Ridwan Shariffdeen wrote:

Hi,

Running valgrind on src/split with the following command reports a memory
error. I have attached the valgrind output (i.e. Use of uninitialised value)


I couldn't repro this here, and
`src/split` above suggests you're testing the latest version from the repo.
The errors in your attached log suggest issues before main() from split is 
entered.
I.e. the issues seem specific to your setup and not split.

thanks,
Pádraig

bug#58599: `date -d $(date)` error for non en_* locale

[Paul Eggert]

On 10/17/22 07:44, Ruslan Kovtun wrote:

According to "do one thing and do it well" and to the fact of '-d/--date'
option existence, `date` should be able to parse its default output in any
locale.


Patches would be welcome. Good luck getting it to work, though. Many 
date formats are ambiguous, and I don't see how you'd address that.


In the meantime, I suggest sticking to ISO format dates and times with 
UTC, e.g.:


date -d "$(date -u +'%Y-%m-%d %H:%M:%S.%NZ')"

bug#58599: `date -d $(date)` error for non en_* locale

[Ruslan Kovtun]

$ date -d "$( date )"
date: invalid date ‘Пн 17 окт 2022 17:34:00 EEST’

$ date -d "Mon 17 oct 2022 17:34:00 EEST"
Пн 17 окт 2022 17:34:00 EEST

According to "do one thing and do it well" and to the fact of '-d/--date'
option existence, `date` should be able to parse its default output in any
locale.
-- 
Yours faithfully,
Ruslan Kovtun.

bug#58050: [INSTALLED] rm: fix diagnostics on I/O error

[Paul Eggert]

On 9/25/22 07:25, Pádraig Brady wrote:

How about the attached to add a NEWS entry,
and add DS_EMPTY, DS_NONEMPTY enums to make the code easier to read?


Sure, that looks good; thanks.

Oh, I forgot that via code inspection I found a theoretical portability 
bug in fts while I was looking into Bug#58050. I fixed that by 
installing the attached into Gnulib.From e00de604fd7012fd912f7580cd658ed9363ed6ad Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Sun, 25 Sep 2022 18:33:49 -0700
Subject: [PATCH] fts: fix errno handling if dirfd fails
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* lib/fts.c (fts_build): Use proper errno if dirfd failed.
Although I don’t know of any platform where dirfd can fail here,
we might as well get it right.
---
 ChangeLog | 7 +++
 lib/fts.c | 3 ++-
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/ChangeLog b/ChangeLog
index 24553445f6..6027e5ed94 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2022-09-25  Paul Eggert  
+
+	fts: fix errno handling if dirfd fails
+	* lib/fts.c (fts_build): Use proper errno if dirfd failed.
+	Although I don’t know of any platform where dirfd can fail here,
+	we might as well get it right.
+
 2022-09-25  Bruno Haible  
 
 	stdbool: Mostly revert last patch.
diff --git a/lib/fts.c b/lib/fts.c
index 954cbb7b40..5811f6ea20 100644
--- a/lib/fts.c
+++ b/lib/fts.c
@@ -1290,11 +1290,12 @@ fts_build (register FTS *sp, int type)
 dir_fd = dirfd (dp);
 if (dir_fd < 0)
   {
+int dirfd_errno = errno;
 closedir_and_clear (cur->fts_dirp);
 if (type == BREAD)
   {
 cur->fts_info = FTS_DNR;
-cur->fts_errno = errno;
+cur->fts_errno = dirfd_errno;
   }
 return NULL;
   }
-- 
2.37.3

bug#58050: [INSTALLED] rm: fix diagnostics on I/O error

[Pádraig Brady]

On 25/09/2022 00:37, Paul Eggert wrote:

I ran into this problem when attempting to recursively
remove a directory in a filesystem on flaky hardware.
Although the underlying readdir syscall failed with errno == EIO,
rm issued no diagnostic about the I/O error.


This looks good.
How about the attached to add a NEWS entry,
and add DS_EMPTY, DS_NONEMPTY enums to make the code easier to read?

thanks,
Pádraig
diff --git a/NEWS b/NEWS
index d1c400e67..7f4eab921 100644
--- a/NEWS
+++ b/NEWS
@@ -60,6 +60,10 @@ GNU coreutils NEWS-*- outline -*-
   date --debug now diagnoses if multiple --date or --set options are
   specified, as only the last specified is significant in that case.
 
+  rm outputs more accurate diagnostics in the presence of errors
+  when removing directories.  For example EIO will be faithfully
+  diagnosed, rather than being conflated with ENOTEMPTY.
+
 
 * Noteworthy changes in release 9.1 (2022-04-15) [stable]
 
diff --git a/src/remove.c b/src/remove.c
index 0b6754bf7..a19794d5e 100644
--- a/src/remove.c
+++ b/src/remove.c
@@ -164,11 +164,11 @@ write_protected_non_symlink (int fd_cwd,
This is -1 if the directory is empty, 0 if it is nonempty,
and a positive error number if there was trouble determining the status,
e.g., it is not a directory, or permissions problems, or I/O errors.
-   Use *DIR_STATUS is a cache for the status.  */
+   Use *DIR_STATUS as a cache for the status.  */
 static int
 get_dir_status (FTS const *fts, FTSENT const *ent, int *dir_status)
 {
-  if (*dir_status < -1)
+  if (*dir_status == DS_UNKNOWN)
 *dir_status = directory_status (fts->fts_cwd_fd, ent->fts_accpath);
   return *dir_status;
 }
@@ -254,7 +254,7 @@ prompt (FTS const *fts, FTSENT const *ent, bool is_dir,
 prompting the user  */
 if ( ! (x->recursive
 || (x->remove_empty_directories
-&& get_dir_status (fts, ent, dir_status) < 0)))
+&& get_dir_status (fts, ent, dir_status) == DS_EMPTY)))
   {
 write_protected = -1;
 wp_errno = *dir_status <= 0 ? EISDIR : *dir_status;
@@ -273,7 +273,7 @@ prompt (FTS const *fts, FTSENT const *ent, bool is_dir,
   /* Issue the prompt.  */
   if (dirent_type == DT_DIR
   && mode == PA_DESCEND_INTO_DIR
-  && get_dir_status (fts, ent, dir_status) == 0)
+  && get_dir_status (fts, ent, dir_status) == DS_NONEMPTY)
 fprintf (stderr,
  (write_protected
   ? _("%s: descend into write-protected directory %s? ")
@@ -427,14 +427,14 @@ excise (FTS *fts, FTSENT *ent, struct rm_options const *x, bool is_dir)
 static enum RM_status
 rm_fts (FTS *fts, FTSENT *ent, struct rm_options const *x)
 {
-  int dir_status = -2;
+  int dir_status = DS_UNKNOWN;
 
   switch (ent->fts_info)
 {
 case FTS_D:			/* preorder directory */
   if (! x->recursive
   && !(x->remove_empty_directories
-   && get_dir_status (fts, ent, _status) < 0))
+   && get_dir_status (fts, ent, _status) == DS_EMPTY))
 {
   /* This is the first (pre-order) encounter with a directory
  that we cannot delete.
@@ -512,7 +512,7 @@ rm_fts (FTS *fts, FTSENT *ent, struct rm_options const *x)
 enum RM_status s = prompt (fts, ent, true /*is_dir*/, x,
PA_DESCEND_INTO_DIR, _status);
 
-if (s == RM_USER_ACCEPTED && dir_status == -1)
+if (s == RM_USER_ACCEPTED && dir_status == DS_EMPTY)
   {
 /* When we know (from prompt when in interactive mode)
that this is an empty directory, don't prompt twice.  */
diff --git a/src/system.h b/src/system.h
index 91228ec13..c63b66741 100644
--- a/src/system.h
+++ b/src/system.h
@@ -291,6 +291,11 @@ readdir_ignoring_dot_and_dotdot (DIR *dirp)
0 if DIR is a nonempty directory,
and a positive error number if there was trouble determining
whether DIR is an empty or nonempty directory.  */
+enum {
+DS_UNKNOWN = -2,
+DS_EMPTY = -1,
+DS_NONEMPTY = 0,
+};
 static inline int
 directory_status (int fd_cwd, char const *dir)
 {
@@ -316,7 +321,7 @@ directory_status (int fd_cwd, char const *dir)
   no_direntries = !readdir_ignoring_dot_and_dotdot (dirp);
   saved_errno = errno;
   closedir (dirp);
-  return no_direntries && saved_errno == 0 ? -1 : saved_errno;
+  return no_direntries && saved_errno == 0 ? DS_EMPTY : saved_errno;
 }
 
 /* Factor out some of the common --help and --version processing code.  */

bug#58050: [INSTALLED] rm: fix diagnostics on I/O error

[Paul Eggert]

I ran into this problem when attempting to recursively
remove a directory in a filesystem on flaky hardware.
Although the underlying readdir syscall failed with errno == EIO,
rm issued no diagnostic about the I/O error.

Without this patch I see this behavior:

  $ rm -fr baddir
  rm: cannot remove 'baddir': Directory not empty
  $ rm -ir baddir
  rm: descend into directory 'baddir'? y
  rm: remove directory 'baddir'? y
  rm: cannot remove 'baddir': Directory not empty

With this patch I see the following behavior, which
lets the user know about the I/O error when rm tries
to read baddir's directory entries:

  $ rm -fr baddir
  rm: cannot remove 'baddir': Input/output error
  $ rm -ir baddir
  rm: cannot remove 'baddir': Input/output error

* src/remove.c (Ternary): Remove.  All uses removed.
(get_dir_status): New static function.
(prompt): Last arg is now directory status, not ternary.
Return RM_USER_ACCEPTED if user explicitly accepted.
All uses changed.
Report any significant error in directory status right away.
(prompt, rm_fts): Use get_dir_status to get directory status lazily.
(excise): Treat any FTS_DNR errno as being more descriptive, not
just EPERM and EACCESS.  For example, EIO is more descriptive.
(rm_fts): Distinguish more clearly between explicit and implied
user OK.
* src/remove.h (RM_USER_ACCEPTED): New constant.
(VALID_STATUS): Treat it as valid.
* src/system.h (is_empty_dir): Remove, replacing with ...
(directory_status): ... this more-general function.
All uses changed.  Avoid undefined behavior of looking at
a non-null readdir pointer after corresponding closedir.
* tests/rm/rm-readdir-fail.sh: Adjust test of internals
to match current behavior.
---
 src/remove.c| 80 +++--
 src/remove.h|  4 +-
 src/rmdir.c |  3 +-
 src/system.h| 25 ++--
 tests/rm/rm-readdir-fail.sh |  1 +
 5 files changed, 58 insertions(+), 55 deletions(-)

diff --git a/src/remove.c b/src/remove.c
index 6756c409d..0b6754bf7 100644
--- a/src/remove.c
+++ b/src/remove.c
@@ -33,14 +33,6 @@
 #include "xfts.h"
 #include "yesno.h"
 
-enum Ternary
-  {
-T_UNKNOWN = 2,
-T_NO,
-T_YES
-  };
-typedef enum Ternary Ternary;
-
 /* The prompt function may be called twice for a given directory.
The first time, we ask whether to descend into it, and the
second time, we ask whether to remove it.  */
@@ -168,9 +160,23 @@ write_protected_non_symlink (int fd_cwd,
   }
 }
 
-/* Prompt whether to remove FILENAME (ent->, if required via a combination of
+/* Return the status of the directory identified by FTS and ENT.
+   This is -1 if the directory is empty, 0 if it is nonempty,
+   and a positive error number if there was trouble determining the status,
+   e.g., it is not a directory, or permissions problems, or I/O errors.
+   Use *DIR_STATUS is a cache for the status.  */
+static int
+get_dir_status (FTS const *fts, FTSENT const *ent, int *dir_status)
+{
+  if (*dir_status < -1)
+*dir_status = directory_status (fts->fts_cwd_fd, ent->fts_accpath);
+  return *dir_status;
+}
+
+/* Prompt whether to remove FILENAME, if required via a combination of
the options specified by X and/or file attributes.  If the file may
-   be removed, return RM_OK.  If the user declines to remove the file,
+   be removed, return RM_OK or RM_USER_ACCEPTED, the latter if the user
+   was prompted and accepted.  If the user declines to remove the file,
return RM_USER_DECLINED.  If not ignoring missing files and we
cannot lstat FILENAME, then return RM_ERROR.
 
@@ -178,20 +184,16 @@ write_protected_non_symlink (int fd_cwd,
 
Depending on MODE, ask whether to 'descend into' or to 'remove' the
directory FILENAME.  MODE is ignored when FILENAME is not a directory.
-   Set *IS_EMPTY_P to T_YES if FILENAME is an empty directory, and it is
-   appropriate to try to remove it with rmdir (e.g. recursive mode).
-   Don't even try to set *IS_EMPTY_P when MODE == PA_REMOVE_DIR.  */
+   Use and update *DIR_STATUS as needed, via the conventions of
+   get_dir_status.  */
 static enum RM_status
 prompt (FTS const *fts, FTSENT const *ent, bool is_dir,
 struct rm_options const *x, enum Prompt_action mode,
-Ternary *is_empty_p)
+int *dir_status)
 {
   int fd_cwd = fts->fts_cwd_fd;
   char const *full_name = ent->fts_path;
   char const *filename = ent->fts_accpath;
-  if (is_empty_p)
-*is_empty_p = T_UNKNOWN;
-
   struct stat st;
   struct stat *sbuf = 
   cache_stat_init (sbuf);
@@ -199,13 +201,6 @@ prompt (FTS const *fts, FTSENT const *ent, bool is_dir,
   int dirent_type = is_dir ? DT_DIR : DT_UNKNOWN;
   int write_protected = 0;
 
-  bool is_empty = false;
-  if (is_empty_p)
-{
-  is_empty = is_empty_dir (fd_cwd, filename);
-  *is_empty_p = is_empty ? T_YES : T_NO;
-}
-
   /* When nonzero, this indicates that we failed to remove a child entr

bug#57631: Coreutils 9.1 build error with glibc 2.23

[Satadru Pramanik]

Thanks! That solved the issue!

On Tue, Sep 6, 2022 at 3:18 PM Paul Eggert  wrote:

> Thanks for the bug report. Please try this Gnulib patch, which should
> appear in the next Coreutils release:
>
>
> https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=84863a1c4dc8cca8fb0f6f670f67779cdd2d543b
>
>

bug#57631: Coreutils 9.1 build error with glibc 2.23

[Paul Eggert via GNU coreutils Bug Reports]

Thanks for the bug report. Please try this Gnulib patch, which should 
appear in the next Coreutils release:


https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=84863a1c4dc8cca8fb0f6f670f67779cdd2d543b

bug#57631: Coreutils 9.1 build error with glibc 2.23

[Satadru Pramanik]

Hello all,

I'm a dev for the Chromebrew distribution. We're supporting older hardware
with ChromeOS, and we're having some trouble building Coreutils 9.1 against
the glibc 2.23 which comes on older i686 Chromebooks. We are using GCC
12.2, and the mold linker. We have no problems building this with the same
arguments on x86_64 and armv7l with glibc 2.27.

Configure line is:
./configure --prefix=/usr/local --libdir=/usr/local/lib
--mandir=/usr/local/share/man --build=i686-cros-linux-gnu
--host=i686-cros-linux-gnu --target=i686-cros-linux-gnu --program-prefix=''
--program-suffix=''"

The error we are seeing is below. Any ideas on what we should do to work
around this?

(Due to the nature of this hardware, we are unable to update the glibc on
these machines.)

  GEN  src/coreutils.h
  GEN  src/version.c
  GEN  src/version.h
make  all-recursive
make[1]: Entering directory
'/usr/local/tmp/crew/coreutils.20220906165907.dir/coreutils-9.1'
Making all in po
make[2]: Entering directory
'/usr/local/tmp/crew/coreutils.20220906165907.dir/coreutils-9.1/po'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory
'/usr/local/tmp/crew/coreutils.20220906165907.dir/coreutils-9.1/po'
Making all in .
make[2]: Entering directory
'/usr/local/tmp/crew/coreutils.20220906165907.dir/coreutils-9.1'
  CC   lib/libcoreutils_a-long-options.o
  CC   lib/libcoreutils_a-malloca.o
  CC   lib/libcoreutils_a-mbchar.o
  CC   lib/libcoreutils_a-math.o
In file included from /usr/local/include/string.h:630,
 from ./lib/string.h:41,
 from lib/mbchar.h:148,
 from lib/mbchar.c:23:
./lib/string.h:1091:1: error: expected identifier or '(' before
'__extension__'
 1091 | _GL_FUNCDECL_SYS (strndup, char *,
  | ^~~~
make[2]: *** [Makefile:14554: lib/libcoreutils_a-mbchar.o] Error 1
make[2]: *** Waiting for unfinished jobs
make[2]: Leaving directory
'/usr/local/tmp/crew/coreutils.20220906165907.dir/coreutils-9.1'
make[1]: *** [Makefile:21011: all-recursive] Error 1
make[1]: Leaving directory
'/usr/local/tmp/crew/coreutils.20220906165907.dir/coreutils-9.1'
make: *** [Makefile:8269: all] Error 2
coreutils failed to build: `CFLAGS="-O2 -pipe -ffat-lto-objects -fPIC
-fuse-ld=mold  -flto" CXXFLAGS="-O2 -pipe -ffat-lto-objects -fPIC
-fuse-ld=mold  -flto" FCFLAGS="-O2 -pipe -ffat-lto-objects -fPIC
-fuse-ld=mold  -flto" FFLAGS="-O2 -pipe -ffat-lto-objects -fPIC
-fuse-ld=mold  -flto" LDFLAGS="-flto " bash -c make


(We can also provide the docker commands to replicate the docker build
environment we use for this architecture if that would help.)

bug#55910: cp error

[Paul Eggert]

Thanks for the bug report. I installed the attached patch, which should 
fix it. Please give it a try.From b54da709a1f3a6f10ed3150b0ae5269002a1053c Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Sat, 11 Jun 2022 10:49:18 -0700
Subject: [PATCH] =?UTF-8?q?cp:=20fix=20=E2=80=98cp=20-rx=20/=20/mnt?=
 =?UTF-8?q?=E2=80=99?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Problem reported by pkor...@gmail.com (Bug#55910).
* src/copy.c (copy_internal): Treat a relative destination name ""
as if it were "." for the purpose of directory-relative syscalls
like fstatat that might might refer to the destination directory.
---
 NEWS   |  3 +++
 src/copy.c | 50 +++---
 2 files changed, 26 insertions(+), 27 deletions(-)

diff --git a/NEWS b/NEWS
index dd37e1525..a3a55541e 100644
--- a/NEWS
+++ b/NEWS
@@ -4,6 +4,9 @@ GNU coreutils NEWS-*- outline -*-
 
 ** Bug fixes
 
+  'cp -rx / /mnt' no longer complains "cannot create directory /mnt/".
+  [bug introduced in coreutils-9.1]
+
   'mv --backup=simple f d/' no longer mistakenly backs up d/f to f~.
   [bug introduced in coreutils-9.1]
 
diff --git a/src/copy.c b/src/copy.c
index b15d91990..edc822134 100644
--- a/src/copy.c
+++ b/src/copy.c
@@ -1954,6 +1954,7 @@ copy_internal (char const *src_name, char const *dst_name,
   bool restore_dst_mode = false;
   char *earlier_file = NULL;
   char *dst_backup = NULL;
+  char const *drelname = *dst_relname ? dst_relname : ".";
   bool delayed_ok;
   bool copied_as_regular = false;
   bool dest_is_symlink = false;
@@ -1971,7 +1972,7 @@ copy_internal (char const *src_name, char const *dst_name,
   if (x->move_mode)
 {
   if (rename_errno < 0)
-rename_errno = (renameatu (AT_FDCWD, src_name, dst_dirfd, dst_relname,
+rename_errno = (renameatu (AT_FDCWD, src_name, dst_dirfd, drelname,
RENAME_NOREPLACE)
 ? errno : 0);
   nonexistent_dst = *rename_succeeded = new_dst = rename_errno == 0;
@@ -1983,7 +1984,7 @@ copy_internal (char const *src_name, char const *dst_name,
 {
   char const *name = rename_errno == 0 ? dst_name : src_name;
   int dirfd = rename_errno == 0 ? dst_dirfd : AT_FDCWD;
-  char const *relname = rename_errno == 0 ? dst_relname : src_name;
+  char const *relname = rename_errno == 0 ? drelname : src_name;
   int fstatat_flags
 = x->dereference == DEREF_NEVER ? AT_SYMLINK_NOFOLLOW : 0;
   if (follow_fstatat (dirfd, relname, _sb, fstatat_flags) != 0)
@@ -2051,8 +2052,7 @@ copy_internal (char const *src_name, char const *dst_name,
   int fstatat_flags = use_lstat ? AT_SYMLINK_NOFOLLOW : 0;
   if (!use_lstat && nonexistent_dst < 0)
 new_dst = true;
-  else if (follow_fstatat (dst_dirfd, dst_relname, _sb,
-   fstatat_flags)
+  else if (follow_fstatat (dst_dirfd, drelname, _sb, fstatat_flags)
== 0)
 {
   have_dst_lstat = use_lstat;
@@ -2077,7 +2077,7 @@ copy_internal (char const *src_name, char const *dst_name,
   bool return_now = false;
 
   if (x->interactive != I_ALWAYS_NO
-  && ! same_file_ok (src_name, _sb, dst_dirfd, dst_relname,
+  && ! same_file_ok (src_name, _sb, dst_dirfd, drelname,
  _sb, x, _now))
 {
   error (0, 0, _("%s and %s are the same file"),
@@ -2140,7 +2140,7 @@ copy_internal (char const *src_name, char const *dst_name,
  cp and mv treat -i and -f differently.  */
   if (x->move_mode)
 {
-  if (abandon_move (x, dst_name, dst_dirfd, dst_relname, _sb))
+  if (abandon_move (x, dst_name, dst_dirfd, drelname, _sb))
 {
   /* Pretend the rename succeeded, so the caller (mv)
  doesn't end up removing the source file.  */
@@ -2321,14 +2321,11 @@ copy_internal (char const *src_name, char const *dst_name,
  Otherwise, use AT_SYMLINK_NOFOLLOW, in case dst_name is a symlink.  */
   if (have_dst_lstat)
 dst_lstat_sb = _sb;
+  else if (fstatat (dst_dirfd, drelname, _buf, AT_SYMLINK_NOFOLLOW)
+   == 0)
+dst_lstat_sb = _buf;
   else
-{
-  if (fstatat (dst_dirfd, dst_relname, _buf,
-   AT_SYMLINK_NOFOLLOW) == 0)
-dst_lstat_sb = _buf;
-  else
-lstat_ok = false;
-}
+lstat_ok = false;
 
   /* Never copy through a symlink we've just created.  */
   if (lstat_ok
@@ -2475,8 +2472,7 @@ copy_internal (char const *src_name, char const *dst_name,
   if (x->move_mode)
 {
   if (rename_errno == EEXIST)
-rename

bug#55910: cp error

[pk]

Package: coreutils

- Boot arch linux live cd 2022.06. It has coreutils 9.1-1.
- mkfs.btrfs /dev/vda
- mount /dev/vda /mnt
- cp -ax / /mnt
cp: cannot create directory '/mnt/': No such file or directory

If relevant: strace says that newfstatat and mkdirat have been given
"" as pathname and return ENOENT.

Instead, the exact same steps work on arch linux 2022.03, which has
coreutils 9.0-2. Note that -x should prevent trying to copy /mnt under
itself; on 2022.03, there is a proper error message for cp -a / /mnt
without -x.

bug#48085: date -d greater than 23 years ago gives error invalid date

[Paul Eggert]

On 4/28/21 16:23, Mark Krenz wrote:

So I'm not sure if this is a problem with coreutils or a change in the
zoneinfo database. Any ideas?


This appears to be a problem in the GNU C library, when its mktime 
deciphers the relatively unusual time zone history of Indiana.


I installed the attached patch into Gnulib and propagated it into 
Coreutils, so the issue should be fixed in the next release of GNU 
Coreutils. Eventually this patch should migrate from Gnulib to glibc so 
that other apps get the fix. Thanks for reporting the issue.From 06b2e943be39284783ff81ac6c9503200f41dba3 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Sat, 19 Feb 2022 15:04:43 -0800
Subject: [PATCH] mktime: improve heuristic for ca-1986 Indiana DST

Problem reported by Mark Krenz .
* lib/mktime.c (__mktime_internal): Be more generous about
accepting arguments with the wrong value of tm_isdst, by falling
back to a one-hour DST difference if we find no nearby DST that is
unusual.  This fixes a problem where "1986-04-28 00:00 EDT" was
rejected when TZ="America/Indianapolis" because the nearest DST
timestamp occurred in 1970, a temporal distance too great for the
old heuristic.  This also also narrows the search a bit, which
is a minor performance win.
* m4/mktime.m4 (gl_FUNC_MKTIME_WORKS):
Check for putenv failures and for Bug#48085.
* tests/test-parse-datetime.c (main):
Test for setenv failures and for Bug#48085.
---
 ChangeLog   | 17 +
 lib/mktime.c| 28 
 m4/mktime.m4| 29 +
 tests/test-parse-datetime.c | 21 +++--
 4 files changed, 81 insertions(+), 14 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 4bf0cec7f0..4d56be83d4 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,20 @@
+2022-02-19  Paul Eggert  
+
+	mktime: improve heuristic for ca-1986 Indiana DST
+	Problem reported by Mark Krenz .
+	* lib/mktime.c (__mktime_internal): Be more generous about
+	accepting arguments with the wrong value of tm_isdst, by falling
+	back to a one-hour DST difference if we find no nearby DST that is
+	unusual.  This fixes a problem where "1986-04-28 00:00 EDT" was
+	rejected when TZ="America/Indianapolis" because the nearest DST
+	timestamp occurred in 1970, a temporal distance too great for the
+	old heuristic.  This also also narrows the search a bit, which
+	is a minor performance win.
+	* m4/mktime.m4 (gl_FUNC_MKTIME_WORKS):
+	Check for putenv failures and for Bug#48085.
+	* tests/test-parse-datetime.c (main):
+	Test for setenv failures and for Bug#48085.
+
 2022-02-12  Paul Eggert  
 
 	filevercmp: fix several unexpected results
diff --git a/lib/mktime.c b/lib/mktime.c
index aa12e28e16..7dc9d67ef9 100644
--- a/lib/mktime.c
+++ b/lib/mktime.c
@@ -429,8 +429,13 @@ __mktime_internal (struct tm *tp,
 	 time with the right value, and use its UTC offset.
 
 	 Heuristic: probe the adjacent timestamps in both directions,
-	 looking for the desired isdst.  This should work for all real
-	 time zone histories in the tz database.  */
+	 looking for the desired isdst.  If none is found within a
+	 reasonable duration bound, assume a one-hour DST difference.
+	 This should work for all real time zone histories in the tz
+	 database.  */
+
+  /* +1 if we wanted standard time but got DST, -1 if the reverse.  */
+  int dst_difference = (isdst == 0) - (tm.tm_isdst == 0);
 
   /* Distance between probes when looking for a DST boundary.  In
 	 tzdata2003a, the shortest period of DST is 601200 seconds
@@ -441,12 +446,14 @@ __mktime_internal (struct tm *tp,
 	 periods when probing.  */
   int stride = 601200;
 
-  /* The longest period of DST in tzdata2003a is 536454000 seconds
-	 (e.g., America/Jujuy starting 1946-10-01 01:00).  The longest
-	 period of non-DST is much longer, but it makes no real sense
-	 to search for more than a year of non-DST, so use the DST
-	 max.  */
-  int duration_max = 536454000;
+  /* In TZDB 2021e, the longest period of DST (or of non-DST), in
+	 which the DST (or adjacent DST) difference is not one hour,
+	 is 457243209 seconds: e.g., America/Cambridge_Bay with leap
+	 seconds, starting 1965-10-31 00:00 in a switch from
+	 double-daylight time (-05) to standard time (-07), and
+	 continuing to 1980-04-27 02:00 in a switch from standard time
+	 (-07) to daylight time (-06).  */
+  int duration_max = 457243209;
 
   /* Search in both directions, so the maximum distance is half
 	 the duration; add the stride to avoid off-by-1 problems.  */
@@ -483,6 +490,11 @@ __mktime_internal (struct tm *tp,
 	  }
 	  }
 
+  /* No unusual DST offset was found nearby.  Assume one-hour DST.  */
+  t += 60 * 60 * dst_difference;
+  if (mktime_min <= t && t <= mktime_max && convert_time (convert, t, ))
+	goto offset_found;
+
   __set_errno (EOVERFLOW);
   return -1;
 }
diff --git 

bug#53674: Docker error code: 0x794c7630

[Bernhard Voelker]

tag 53674 notabug
close 53674
stop

On 2/1/22 03:38, Alexandre Louisdhon wrote:
> Error-  tail: unrecognized file system type 0x794c7630 for
> ‘/var/log/syslog’.

Thanks for the report.

That docker image seems to use a quite old coreutils version:
overlayfs - commonly used with Docker containers - has been added
in version 8.25 which was released in 2016.
Consider upgrading Coreutils if possible - we're at 9.0 currently.

See https://www.gnu.org/software/coreutils/filesystems.html for
more details.

Have a nice day,
Berny

bug#53674: Docker error code: 0x794c7630

[Alexandre Louisdhon]

Error-  tail: unrecognized file system type 0x794c7630 for
‘/var/log/syslog’.

What happened:
First, I git clone a bit bucket repository that contained PHP.
Second, I used git checkout to switch to an existing branch.
Third, I used docker-compose up in my bash terminal.
Finally, I received the error message above.

Please, help me resolve this.

Thank you, Alexandre Louisdhon

bug#53262: chmod 9.0 failing, where 8.29 succeeds - but no error message

[Pádraig Brady]

On 15/01/2022 01:09, Paul Eggert wrote:

Thanks for reporting that. This is a duplicate of bug#50784[1], which
was fixed[2] in September.

Perhaps we should generate a new Coreutils soon, since this bug has been
reported three times now.

[1]: https://bugs.gnu.org/50784
[2]:
https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=e8b56ebd536e82b15542a00c888109471936bfda


Yes I'm planning a new release in a few weeks.

cheers,
Pádraig

bug#53262: chmod 9.0 failing, where 8.29 succeeds - but no error message

[Paul Eggert]

Thanks for reporting that. This is a duplicate of bug#50784[1], which 
was fixed[2] in September.


Perhaps we should generate a new Coreutils soon, since this bug has been 
reported three times now.


[1]: https://bugs.gnu.org/50784
[2]: 
https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=e8b56ebd536e82b15542a00c888109471936bfda

bug#53262: chmod 9.0 failing, where 8.29 succeeds - but no error message

[Jost, Martin (Nokia - DE/Ulm)]

Hello,

we found a case, where chmod from coreutils 9.0 fails (exit value 1), while the 
one from 8.29 succeeds. (exit value 0)
Unfortunately, no (error) message is given, just the exit value is 0 and 1 
respectively.

Here is the example:

== 8.29: fine

>chmod --version
chmod (GNU coreutils) 8.29
...
> chmod -R go+r-w MB_192378  
> echo $?
0

Exit value 0, everyone happy.

== 8.30: bad

> /build/home//coreutils-9.0/src/chmod --version
chmod (GNU coreutils) 9.0


> /build/home/.../coreutils-9.0/src/chmod -R go+r-w MB_192378
> echo $?
1

Exit value 1 - no error message given.

==

Notes:
1 this call, using "go+r-w" is generated by some tool, outside our immediate 
control.
   I would expect 'go+r,go-w'. Can you confirm to me, whether the used syntax 
is ok ?
   (From the description in the info-page, I'm not sure; OTOH no diagnostic 
given for both versions.)

1 a I tried " chmod -R go+r,go-w" with 9.0, but that had the same behaviour (No 
error indication; exit value 1)

2 How can I (try to) find what is causing the bug ?
  (Note: The tree I'm changing, is rather big...)
  I'm currently trying to run the command "under" strace in an emacs shell 
buffer - but I'm afraid that will be overwhelming...

3. The chmod is done on a NFS mounted FS
The chmod binary - both 8.29 as well as 9.0 - are located on NFS as well.

4. The "configure' options for 8.29 and 9.0 are the same; both are build on the 
same machine. (*)
Both were build after a 'make distclean' in short succession (a few hours); 
8.29 intended to "downdate" to that one again, after I ran into the problem.
   The test runs above, had been running on a different machine compared to the 
build machine.
   (*) I just learned the hard way, that e.g. 'GNU cp' is silently ignoring 
options like capabilities or ACL, if the needed development (header) packages 
aren't installed on the build  machine. That triggered the whole "update" thing.

5. Both 8.29 as well as 9.0 passed 'make check' after compilation.

Regards

Martin

bug#52873: expr unexpected syntax error

[Martin Rixham]

ok I appreciate the explanation.

On Wed, 29 Dec 2021 at 20:58, Paul Eggert  wrote:

> On 12/29/21 12:01, Martin Rixham wrote:
> > What nonsense. I want to parse source code. ')' is not an uncommon line
> of
> > source code. It should work.
>
> Unfortunately, you're asking for what is in general impossible. If the
> left argument of ':' could be any string, then the grammar for 'expr'
> would be ambiguous. Consider the following shell command:
>
> expr '(' : ')'
>
> This outputs ':' because it evaluates the parenthesized string ':'; but
> if the operands of ':' could be any strings it could also be interpreted
> as matching '(' against ')', which means it should output the same thing
> as 'expr a : b', namely '0'.
>
> Of course this means 'expr' was poorly designed in the 1970s, but we're
> stuck with that design now (it's standardized by POSIX), portable code
> must deal with this poor design, and for compatibility reasons it's
> better for GNU expr to support the design, poor as it is.
>
> These days there are much better ways than 'expr' to parse code. For
> example, if you want to count the number of characters in a shell
> variable v, you can use this shell command:
>
> nv=${#v}
>
> This works even if v=')', whereas this:
>
> nv=$(expr "$v" : '.*')
>
> has the bug that you mentioned, plus it's harder to read and it's less
> efficient.
>

bug#52873: expr unexpected syntax error

[Martin Rixham]

What nonsense. I want to parse source code. ')' is not an uncommon line of
source code. It should work.

On Wed, 29 Dec 2021 at 19:52, Paul Eggert  wrote:

> On 12/29/21 08:31, Davide Brini wrote:
> > I think you need to use '+' before the offending token
>
> Yes. That's a GNU extension. If you want to be portable to any POSIX
> implementation, you can use this instead:
>
> expr "X(" : '.*' - 1
>
> A similar example is given in the POSIX spec for 'expr':
>
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/expr.html
>
> As this is not a bug, I'm closing the bug report.
>

bug#52873: expr unexpected syntax error

[Paul Eggert]

On 12/29/21 12:01, Martin Rixham wrote:

What nonsense. I want to parse source code. ')' is not an uncommon line of
source code. It should work.


Unfortunately, you're asking for what is in general impossible. If the 
left argument of ':' could be any string, then the grammar for 'expr' 
would be ambiguous. Consider the following shell command:


expr '(' : ')'

This outputs ':' because it evaluates the parenthesized string ':'; but 
if the operands of ':' could be any strings it could also be interpreted 
as matching '(' against ')', which means it should output the same thing 
as 'expr a : b', namely '0'.


Of course this means 'expr' was poorly designed in the 1970s, but we're 
stuck with that design now (it's standardized by POSIX), portable code 
must deal with this poor design, and for compatibility reasons it's 
better for GNU expr to support the design, poor as it is.


These days there are much better ways than 'expr' to parse code. For 
example, if you want to count the number of characters in a shell 
variable v, you can use this shell command:


nv=${#v}

This works even if v=')', whereas this:

nv=$(expr "$v" : '.*')

has the bug that you mentioned, plus it's harder to read and it's less 
efficient.

bug#52873: expr unexpected syntax error

[Paul Eggert]

On 12/29/21 08:31, Davide Brini wrote:

I think you need to use '+' before the offending token


Yes. That's a GNU extension. If you want to be portable to any POSIX 
implementation, you can use this instead:


expr "X(" : '.*' - 1

A similar example is given in the POSIX spec for 'expr':

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/expr.html

As this is not a bug, I'm closing the bug report.

bug#52873: expr unexpected syntax error

[Davide Brini]

On Wed, 29 Dec 2021 12:42:24 +, Martin Rixham
 wrote:

> I'm getting an error from the following:
>
> [martin@fedora ~]$ expr ')' : '.*'
> expr: syntax error: unexpected ')'
>
> There also seems to be a similar problem with:
>
> expr '(' : '.*'

I think you need to use '+' before the offending token, at least according
to the man page:

   + TOKEN
  interpret TOKEN as a string, even if it is a
  keyword like 'match' or an operator like '/'

And indeed:

$ expr '+' ')' : '.*'
1

--
D.

bug#52873: expr unexpected syntax error

[Martin Rixham]

I'm getting an error from the following:

[martin@fedora ~]$ expr ')' : '.*'
expr: syntax error: unexpected ')'

There also seems to be a similar problem with:

expr '(' : '.*'

Here's the version:

[martin@fedora ~]$ expr --version
expr (GNU coreutils) 8.32
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <
https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Mike Parker, James Youngman, and Paul Eggert.

And a uname for good measure:

[martin@fedora ~]$ uname -a
Linux fedora 5.15.7-200.fc35.x86_64 #1 SMP Wed Dec 8 19:00:47 UTC 2021
x86_64 x86_64 x86_64 GNU/Linux

Thanks,

Martin

bug#52122: mv: deletes src file on error

[Frank Busse]

On Fri, 26 Nov 2021 18:54:54 +0100
Bernhard Voelker  wrote:

> On 11/26/21 13:23, Frank Busse wrote:
> > I tried it several times with checking the timestamps/md5sums of the
> > files but after remounting the stick it doesn't happen anymore?! I
> > guess it was a hiccup somewhere else in the system, sorry.
> 
> Perhaps the USB stick was removed from the system before the kernel
> could flush the data?

No, I tried it several times with the stick still mounted. Strangely
enough, copying with a different name worked fine. Maybe a kernel or
hardware issue - no idea.


Best,

Frank

bug#52122: mv: deletes src file on error

[Paul Eggert]

On 11/26/21 04:23, Frank Busse wrote:

I
guess it was a hiccup somewhere else in the system, sorry.


Thanks for following up; closing the bug report.

bug#52122: mv: deletes src file on error

[Bernhard Voelker]

On 11/26/21 13:23, Frank Busse wrote:
> I tried it several times with checking the timestamps/md5sums of the
> files but after remounting the stick it doesn't happen anymore?! I
> guess it was a hiccup somewhere else in the system, sorry.

Perhaps the USB stick was removed from the system before the kernel
could flush the data?

Have a nice day,
Berny

bug#52122: mv: deletes src file on error

[Frank Busse]

On Fri, 26 Nov 2021 12:05:21 +
Chris Elvidge  wrote:

> Is your USB stick (V)FAT(32) (or similar) formatted?

It's FAT32.

> > The error is fine but mv deletes /src/foo and keeps mnt/dst/foo,
> > meaning that the data of the new file is lost. Is this the intended
> > behaviour? I'm using Coreutils 9.0.
> 
> Didn't reproduce this (as root).
> mv (GNU coreutils) 8.32.179-c7577

I tried it several times with checking the timestamps/md5sums of the
files but after remounting the stick it doesn't happen anymore?! I
guess it was a hiccup somewhere else in the system, sorry.


Kind regards,

Frank

bug#52122: mv: deletes src file on error

[Chris Elvidge]

On 26/11/2021 11:07 am, Frank Busse wrote:

Hi,


Given two files: an old version of "foo" on a mounted USB stick:

/mnt/dst/foo

and a new version of "foo" in /src/foo on the system's hard drive. When
I do:

sudo mv /src/foo /mnt/dst/foo

I get the following error:

mv: failed to preserve ownership for '/mnt/dst/foo': Operation not permitted



Is your USB stick (V)FAT(32) (or similar) formatted?



The error is fine but mv deletes /src/foo and keeps mnt/dst/foo,
meaning that the data of the new file is lost. Is this the intended
behaviour? I'm using Coreutils 9.0.


Didn't reproduce this (as root).
mv (GNU coreutils) 8.32.179-c7577




Kind regards,

Frank







--

Chris Elvidge

bug#52122: mv: deletes src file on error

[Frank Busse]

Hi,


Given two files: an old version of "foo" on a mounted USB stick:

/mnt/dst/foo

and a new version of "foo" in /src/foo on the system's hard drive. When
I do:

sudo mv /src/foo /mnt/dst/foo

I get the following error:

mv: failed to preserve ownership for '/mnt/dst/foo': Operation not permitted

The error is fine but mv deletes /src/foo and keeps mnt/dst/foo,
meaning that the data of the new file is lost. Is this the intended
behaviour? I'm using Coreutils 9.0.


Kind regards,

Frank

bug#50085: fatal error: parse-datetime.tab.h: No such file or directory

[softwarebugreports via GNU coreutils Bug Reports]

Thanks for your patience and clarification. I was able to get it working 
properly with the latest master:

RUN git clone --branch master --single-branch 
https://git.savannah.gnu.org/git/coreutils.git \
&& cd coreutils \
&& export FORCE_UNSAFE_CONFIGURE=1 \
&& ./bootstrap \
&& ./configure \
--disable-gcc-warnings \
&& make

‐‐‐ Original Message ‐‐‐

On Wednesday, August 18th, 2021 at 11:01 AM, Paul Eggert  
wrote:

> 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 8002ca7b56acb46b42eeac4a343e112a8ee283cf (2020-09-13).
>
> Combinations like that are not intended to work. You need to use the
>
> Gnulib commit given as a submodule in the Coreutils commit.

bug#50085: fatal error: parse-datetime.tab.h: No such file or directory

[Paul Eggert]

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 8002ca7b56acb46b42eeac4a343e112a8ee283cf (2020-09-13). 
Combinations like that are not intended to work. You need to use the 
Gnulib commit given as a submodule in the Coreutils commit.

bug#50085: fatal error: parse-datetime.tab.h: No such file or directory

[softwarebugreports via GNU coreutils Bug Reports]

Thank you for the help! I tried using 8002ca7b56acb46b42eeac4a343e112a8ee283cf 
and the latest commits from master and received the following errors while 
running bootstrap now:
#10 154.1 Copying file m4/stdint_h.m4
#10 154.2 Copying file m4/threadlib.m4
#10 154.2 Copying file m4/uintmax_t.m4
#10 154.2 Copying file m4/visibility.m4
#10 154.2 Copying file m4/wchar_t.m4
#10 154.3 Copying file m4/wint_t.m4
#10 154.3 Copying file m4/xsize.m4
#10 154.3 Copying file po/Makefile.in.in
#10 154.3 Copying file po/Makevars.template
#10 154.4 Copying file po/Rules-quot
#10 154.4 Copying file po/boldquot.sed
#10 154.4 Copying file po/en@boldquot.header
#10 154.5 Copying file po/en@quot.header
#10 154.5 Copying file po/insert-header.sin
#10 154.5 Copying file po/quot.sed
#10 154.5 Copying file po/remove-potcdate.sin
#10 156.1 ./bootstrap: gnulib/gnulib-tool--no-changelog   
--aux-dir=build-aux   --doc-base=doc   --lib=libcoreutils   --m4-base=m4/   
--source-base=lib/   --tests-base=tests   --local-dir=gl   
--tests-base=gnulib-tests --with-tests --symlink --makefile-name=gnulib.mk
#10 156.1--import ...
#10 159.5 gnulib-tool: warning: module diacrit doesn't exist
#10 169.0 1 out of 1 hunk FAILED -- saving rejects to file 
/tmp/glgMTDiu/tempname.rej
#10 169.0 gnulib/gnulib-tool: *** patch file gl/modules/tempname.diff didn't 
apply cleanly
#10 169.0 gnulib/gnulib-tool: *** Stop.
#10 169.1 1 out of 1 hunk FAILED -- saving rejects to file 
/tmp/glgMTDiu/tempname.rej
#10 169.1 gnulib/gnulib-tool: *** patch file gl/modules/tempname.diff didn't 
apply cleanly
#10 169.1 gnulib/gnulib-tool: *** Stop.
#10 177.2 1 out of 1 hunk FAILED -- saving rejects to file 
/tmp/glgMTDiu/tempname.rej
#10 177.2 gnulib/gnulib-tool: *** patch file gl/modules/tempname.diff didn't 
apply cleanly
#10 177.2 gnulib/gnulib-tool: *** Stop.
#10 177.2 ./bootstrap: gnulib-tool failed
#10 ERROR: executor failed running [/bin/sh -c git clone --branch v8.32 
--single-branch https://git.savannah.gnu.org/git/coreutils.git && cd 
coreutils && git clone https://git.savannah.gnu.org/git/gnulib.git && 
export FORCE_UNSAFE_CONFIGURE=1 && ./bootstrap --gnulib-srcdir=gnulib 
--no-git && ./configure --disable-gcc-warnings --disable-nls 
--enable-install-program=hostname --enable-single-binary=symlinks 
--without-gmp && make]: exit code: 1
--
> [6/6] RUN git clone --branch v8.32 --single-branch 
> https://git.savannah.gnu.org/git/coreutils.git && cd coreutils && git 
> clone https://git.savannah.gnu.org/git/gnulib.git && export 
> FORCE_UNSAFE_CONFIGURE=1 && ./bootstrap --gnulib-srcdir=gnulib --no-git   
>   && ./configure --disable-gcc-warnings --disable-nls 
> --enable-install-program=hostname --enable-single-binary=symlinks 
> --without-gmp && make:
--
executor failed running [/bin/sh -c git clone --branch v8.32 --single-branch 
https://git.savannah.gnu.org/git/coreutils.git && cd coreutils && git 
clone https://git.savannah.gnu.org/git/gnulib.git && export 
FORCE_UNSAFE_CONFIGURE=1 && ./bootstrap --gnulib-srcdir=gnulib --no-git 
&& ./configure --disable-gcc-warnings --disable-nls 
--enable-install-program=hostname --enable-single-binary=symlinks 
--without-gmp && make]: exit code: 1
make: *** [Makefile:9: build-coreutils] Error 1

My Dockerfile has the following content:
...
RUN git clone --branch v8.32 --single-branch 
https://git.savannah.gnu.org/git/coreutils.git \
&& cd coreutils \
&& git clone https://git.savannah.gnu.org/git/gnulib.git \
&& export FORCE_UNSAFE_CONFIGURE=1 \
&& ./bootstrap --gnulib-srcdir=gnulib --no-git \
&& ./configure \
--disable-gcc-warnings \
--disable-nls \
--enable-install-program=hostname \
--enable-single-binary=symlinks \
--without-gmp \
&& make

Am I running bootstrap with improper flags or without necessary environment 
variables?

‐‐‐ Original Message ‐‐‐

On Tuesday, August 17th, 2021 at 11:32 AM, Pádraig Brady  
wrote:

> On 17/08/2021 16:16, Pádraig Brady wrote:
>
> > On 17/08/2021 02:32, softwarebugreports via GNU coreutils Bug Reports wrote:
> >
> > > I receive the following error when using make with coreutils in a alpine 
> > > based docker container:
>
> > > > #10 304.5 parse-datetime.tab.c:658:10: fatal error: 
> > > > parse-datetime.tab.h: No such file or directory
>
> > > > RUN git clone --branch v8.32 --single-branch 
> > > > https://git.savannah.gnu.org/git/coreutils.git \
> > > >
> > > > && cd coreutils \
> > > >
> > > > && export FORCE_UNSAFE_CONFIG

bug#50085: fatal error: parse-datetime.tab.h: No such file or directory

[Pádraig Brady]

On 17/08/2021 16:16, Pádraig Brady wrote:

On 17/08/2021 02:32, softwarebugreports via GNU coreutils Bug Reports wrote:

I receive the following error when using make with coreutils in a alpine based 
docker container:




#10 304.5 parse-datetime.tab.c:658:10: fatal error: parse-datetime.tab.h: No 
such file or directory




RUN git clone --branch v8.32 --single-branch 
https://git.savannah.gnu.org/git/coreutils.git \
&& cd coreutils \
&& export FORCE_UNSAFE_CONFIGURE=1 \
&& ./bootstrap \
&& ./configure \
--disable-gcc-warnings \
--disable-nls \
--enable-install-program=hostname \
--enable-single-binary=symlinks \
--without-gmp \
&& make


Is there something I can try to correct this error?


Seems this is related bison >= 3.7 which Bruno fixed in:
https://lists.gnu.org/archive/html/bug-gnulib/2020-07/msg00178.html

That would have to be integrated as a patch against your coreutils sources.


Actually there were a few more fixes in that file,
so it's best base adjustments off this version:
https://github.com/coreutils/gnulib/blob/8002ca7b/modules/parse-datetime

cheers,
Pádraig

bug#50085: fatal error: parse-datetime.tab.h: No such file or directory

[Pádraig Brady]

On 17/08/2021 02:32, softwarebugreports via GNU coreutils Bug Reports wrote:

I receive the following error when using make with coreutils in a alpine based 
docker container:


#10 304.0 CC lib/mkdir-p.o
#10 304.1 CC lib/modechange.o
#10 304.1 CC lib/mpsort.o
#10 304.2 CC lib/nproc.o
#10 304.2 CC lib/nstrftime.o
#10 304.3 CC lib/openat-die.o
#10 304.4 CC lib/openat-safer.o
#10 304.4 CC lib/opendirat.o
#10 304.4 CC lib/parse-datetime.o
#10 304.5 parse-datetime.tab.c:658:10: fatal error: parse-datetime.tab.h: No 
such file or directory
#10 304.5 compilation terminated.
#10 304.5 make[2]: *** [Makefile:10276: lib/parse-datetime.o] Error 1
#10 304.5 make[2]: Leaving directory '/coreutils'
#10 304.5 make[1]: *** [Makefile:12913: all-recursive] Error 1
#10 304.5 make[1]: Leaving directory '/coreutils'
#10 304.5 make: *** [Makefile:7030: all] Error 2
#10 ERROR: executor failed running [/bin/sh -c git clone --branch v8.32 --single-branch 
https://git.savannah.gnu.org/git/coreutils.git && export FORCE_UNSAFE_CONFIGURE=1 && 
./bootstrap && ./configure --disable-gcc-warnings --disable-nls --enable-install-program=hostname 
--enable-single-binary=symlinks --without-gmp && make]: exit code: 2
--

[6/6] RUN git clone --branch v8.32 --single-branch https://git.savannah.gnu.org/git/coreutils.git && cd 
coreutils && export FORCE_UNSAFE_CONFIGURE=1 && ./bootstrap && ./configure 
--disable-gcc-warnings --disable-nls --enable-install-program=hostname --enable-single-binary=symlinks --without-gmp 
&& make:

--
executor failed running [/bin/sh -c git clone --branch v8.32 --single-branch 
https://git.savannah.gnu.org/git/coreutils.git && export FORCE_UNSAFE_CONFIGURE=1 && 
./bootstrap && ./configure --disable-gcc-warnings --disable-nls --enable-install-program=hostname 
--enable-single-binary=symlinks --without-gmp && make]: exit code: 2
make: *** [Makefile:9: build-coreutils] Error 1


My Dockerfile has the following content:


FROM alpine:3.14.1

ENV CFLAGS "-static"

RUN mkdir /static/

RUN apk add --no-cache \
acl-dev \
attr-dev \
autoconf \
automake \
bash \
bison \
coreutils \
gcc \
gettext-dev \
git \
gperf \
make \
musl-dev \
patch \
perl \
perl \
rsync \
texinfo \
utmps-dev \
wget \
xz

RUN git clone --branch v8.32 --single-branch 
https://git.savannah.gnu.org/git/coreutils.git \
&& cd coreutils \
&& export FORCE_UNSAFE_CONFIGURE=1 \
&& ./bootstrap \
&& ./configure \
--disable-gcc-warnings \
--disable-nls \
--enable-install-program=hostname \
--enable-single-binary=symlinks \
--without-gmp \
&& make


Is there something I can try to correct this error?


Seems this is related bison >= 3.7 which Bruno fixed in:
https://lists.gnu.org/archive/html/bug-gnulib/2020-07/msg00178.html

That would have to be integrated as a patch against your coreutils sources.

cheers,
Pádraig

bug#50085: fatal error: parse-datetime.tab.h: No such file or directory

[softwarebugreports via GNU coreutils Bug Reports]

I receive the following error when using make with coreutils in a alpine based 
docker container:

> #10 304.0 CC lib/mkdir-p.o
> #10 304.1 CC lib/modechange.o
> #10 304.1 CC lib/mpsort.o
> #10 304.2 CC lib/nproc.o
> #10 304.2 CC lib/nstrftime.o
> #10 304.3 CC lib/openat-die.o
> #10 304.4 CC lib/openat-safer.o
> #10 304.4 CC lib/opendirat.o
> #10 304.4 CC lib/parse-datetime.o
> #10 304.5 parse-datetime.tab.c:658:10: fatal error: parse-datetime.tab.h: No 
> such file or directory
> #10 304.5 compilation terminated.
> #10 304.5 make[2]: *** [Makefile:10276: lib/parse-datetime.o] Error 1
> #10 304.5 make[2]: Leaving directory '/coreutils'
> #10 304.5 make[1]: *** [Makefile:12913: all-recursive] Error 1
> #10 304.5 make[1]: Leaving directory '/coreutils'
> #10 304.5 make: *** [Makefile:7030: all] Error 2
> #10 ERROR: executor failed running [/bin/sh -c git clone --branch v8.32 
> --single-branch https://git.savannah.gnu.org/git/coreutils.git && export 
> FORCE_UNSAFE_CONFIGURE=1 && ./bootstrap && ./configure --disable-gcc-warnings 
> --disable-nls --enable-install-program=hostname 
> --enable-single-binary=symlinks --without-gmp && make]: exit code: 2
> --
>> [6/6] RUN git clone --branch v8.32 --single-branch 
>> https://git.savannah.gnu.org/git/coreutils.git && cd coreutils && export 
>> FORCE_UNSAFE_CONFIGURE=1 && ./bootstrap && ./configure 
>> --disable-gcc-warnings --disable-nls --enable-install-program=hostname 
>> --enable-single-binary=symlinks --without-gmp && make:
> --
> executor failed running [/bin/sh -c git clone --branch v8.32 --single-branch 
> https://git.savannah.gnu.org/git/coreutils.git && export 
> FORCE_UNSAFE_CONFIGURE=1 && ./bootstrap && ./configure --disable-gcc-warnings 
> --disable-nls --enable-install-program=hostname 
> --enable-single-binary=symlinks --without-gmp && make]: exit code: 2
> make: *** [Makefile:9: build-coreutils] Error 1

My Dockerfile has the following content:

> FROM alpine:3.14.1
>
> ENV CFLAGS "-static"
>
> RUN mkdir /static/
>
> RUN apk add --no-cache \
> acl-dev \
> attr-dev \
> autoconf \
> automake \
> bash \
> bison \
> coreutils \
> gcc \
> gettext-dev \
> git \
> gperf \
> make \
> musl-dev \
> patch \
> perl \
> perl \
> rsync \
> texinfo \
> utmps-dev \
> wget \
> xz
>
> RUN git clone --branch v8.32 --single-branch 
> https://git.savannah.gnu.org/git/coreutils.git \
> && cd coreutils \
> && export FORCE_UNSAFE_CONFIGURE=1 \
> && ./bootstrap \
> && ./configure \
> --disable-gcc-warnings \
> --disable-nls \
> --enable-install-program=hostname \
> --enable-single-binary=symlinks \
> --without-gmp \
> && make

Is there something I can try to correct this error?

bug#50070: chmod reads uninitialized variables when fts_info is an error and -v is set, leading to random error messages

[Paul Eggert]

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 Debertol (Bug#50070).
* NEWS: Mention the fix.
* src/chmod.c (struct change_status): New struct, replacing the
old enum Change_status.  All uses changed.
(describe_change): Distinguish between cases depending on
whether 'stat' or its equivalent succeeded.  Report a line
of output even if 'stat' failed, as that matches the documentation.
Rework to avoid casts.
(process_file): Do not output nonsense modes computed from
uninitialized storage, removing a couple of IF_LINTs.  Simplify by
defaulting to CH_NO_STAT.
---
 NEWS|   3 ++
 src/chmod.c | 127 ++--
 2 files changed, 67 insertions(+), 63 deletions(-)

diff --git a/NEWS b/NEWS
index e14de1397..ddec56bdf 100644
--- a/NEWS
+++ b/NEWS
@@ -4,6 +4,9 @@ GNU coreutils NEWS-*- outline -*-
 
 ** Bug fixes
 
+  chmod -v no longer misreports modes of dangling symlinks.
+  [bug introduced in coreutils-5.3.0]
+
   cp -a --attributes-only now never removes destination files,
   even if the destination files are hardlinked, or the source
   is a non regular file.
diff --git a/src/chmod.c b/src/chmod.c
index 160a0c537..4447e784e 100644
--- a/src/chmod.c
+++ b/src/chmod.c
@@ -39,12 +39,19 @@
   proper_name ("David MacKenzie"), \
   proper_name ("Jim Meyering")
 
-enum Change_status
+struct change_status
 {
-  CH_NOT_APPLIED,
-  CH_SUCCEEDED,
-  CH_FAILED,
-  CH_NO_CHANGE_REQUESTED
+  enum
+{
+  CH_NO_STAT,
+  CH_NOT_APPLIED,
+  CH_FAILED,
+  CH_NO_CHANGE_REQUESTED,
+  CH_SUCCEEDED
+}
+status;
+  mode_t old_mode;
+  mode_t new_mode;
 };
 
 enum Verbosity
@@ -136,30 +143,42 @@ mode_changed (int dir_fd, char const *file, char const *file_full_name,
 }
 
 /* Tell the user how/if the MODE of FILE has been changed.
-   CHANGED describes what (if anything) has happened. */
+   CH describes what (if anything) has happened. */
 
 static void
-describe_change (char const *file, mode_t old_mode, mode_t mode,
- enum Change_status changed)
+describe_change (char const *file, struct change_status const *ch)
 {
   char perms[12];		/* "-rwxrwxrwx" ls-style modes. */
   char old_perms[12];
   char const *fmt;
+  char const *quoted_file = quoteaf (file);
 
-  if (changed == CH_NOT_APPLIED)
+  switch (ch->status)
 {
+case CH_NOT_APPLIED:
   printf (_("neither symbolic link %s nor referent has been changed\n"),
-  quoteaf (file));
+  quoted_file);
   return;
-}
 
-  strmode (mode, perms);
+case CH_NO_STAT:
+  printf (_("%s could not be accessed\n"), quoted_file);
+  return;
+
+default:
+  break;
+  }
+
+  unsigned long int
+old_m = ch->old_mode & CHMOD_MODE_BITS,
+m = ch->new_mode & CHMOD_MODE_BITS;
+
+  strmode (ch->new_mode, perms);
   perms[10] = '\0';		/* Remove trailing space.  */
 
-  strmode (old_mode, old_perms);
+  strmode (ch->old_mode, old_perms);
   old_perms[10] = '\0';		/* Remove trailing space.  */
 
-  switch (changed)
+  switch (ch->status)
 {
 case CH_SUCCEEDED:
   fmt = _("mode of %s changed from %04lo (%s) to %04lo (%s)\n");
@@ -169,15 +188,12 @@ describe_change (char const *file, mode_t old_mode, mode_t mode,
   break;
 case CH_NO_CHANGE_REQUESTED:
   fmt = _("mode of %s retained as %04lo (%s)\n");
-  printf (fmt, quoteaf (file),
-  (unsigned long int) (mode & CHMOD_MODE_BITS), [1]);
+  printf (fmt, quoted_file, m, [1]);
   return;
 default:
   abort ();
 }
-  printf (fmt, quoteaf (file),
-  (unsigned long int) (old_mode & CHMOD_MODE_BITS), _perms[1],
-  (unsigned long int) (mode & CHMOD_MODE_BITS), [1]);
+  printf (fmt, quoted_file, old_m, _perms[1], m, [1]);
 }
 
 /* Change the mode of FILE.
@@ -190,10 +206,8 @@ process_file (FTS *fts, FTSENT *ent)
   char const *file_full_name = ent->fts_path;
   char const *file = ent->fts_accpath;
   const struct stat *file_stats = ent->fts_statp;
-  mode_t old_mode IF_LINT ( = 0);
-  mode_t new_mode IF_LINT ( = 0);
-  bool ok = true;
-  bool chmod_succeeded = false;
+  struct change_status ch;
+  ch.status = CH_NO_STAT;
 
   switch (ent->fts_info)
 {
@@ -217,27 +231,23 @@ process_file (FTS *fts, FTSENT *ent)
   if (! force_silent)
 error (0, ent->fts_errno, _("cannot access %s"),
    quoteaf (file_full_name));
-  ok = false;
   break;
 
 case FTS_ERR:
   if (! force_silent)
 error (0, ent->fts_errno, "%s", quotef (file_full_name));
-  ok = false;
   break;
 
  

bug#50070: chmod reads uninitialized variables when fts_info is an error and -v is set, leading to random error messages

[Michael Debertol]

Hi,

I noticed that when running chmod with -v on a dangling symlink the 
error message is somewhat random:


> ln -s file-that-does-not-exist lnk

> chmod -w lnk -v

> chmod: cannot operate on dangling symlink 'lnk'

> failed to change mode of 'lnk' from  (-) to  (rwsrwsrwt)

> chmod -w lnk -v

> chmod: cannot operate on dangling symlink 'lnk'

> failed to change mode of 'lnk' from  (-) to 7775 (rwsrwsr-t)

> chmod -w lnk -v

> chmod: cannot operate on dangling symlink 'lnk'

> failed to change mode of 'lnk' from  (-) to 7774 (rwsrwsr-T)


(note that the value for "to" is different)

This appears to be because in the process_file function, old_mode and 
new_mode are only set when ok is true. When chmod encounters a dangling 
symlink, ok will be false and old_mode/new_mode won't be set. However, 
old_mode and new_mode are still accessed for the invocation of 
describe_change if verbosity is set to high, leading to incorrect error 
messages.


I think a better behavior could be to not print the "from mode to mode" 
part of the error message if the file could not be accessed, since it is 
meaningless anyways.


Have a nice day,

Michael

bug#48106: bug: touch utility does not handle file create error properly

[Paul Eggert]

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/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Problem reported by Roland (Bug#48106).
* src/touch.c (touch): Take more care when deciding whether
to use open_errno or utime_errno in the diagnostic.
Stop worrying about SunOS 4 (which as part of the problem),
as it’s long obsolete.  For Solaris 10, verify that EINVAL
really means the file was a directory.
---
 src/touch.c | 34 +++---
 1 file changed, 19 insertions(+), 15 deletions(-)

diff --git a/src/touch.c b/src/touch.c
index 653fd313b..46ddd86bb 100644
--- a/src/touch.c
+++ b/src/touch.c
@@ -122,7 +122,6 @@ get_reldate (struct timespec *result,
 static bool
 touch (char const *file)
 {
-  bool ok;
   int fd = -1;
   int open_errno = 0;
   struct timespec const *t = newtime;
@@ -134,12 +133,7 @@ touch (char const *file)
   /* Try to open FILE, creating it if necessary.  */
   fd = fd_reopen (STDIN_FILENO, file,
   O_WRONLY | O_CREAT | O_NONBLOCK | O_NOCTTY, MODE_RW_UGO);
-
-  /* Don't save a copy of errno if it's EISDIR, since that would lead
- touch to give a bogus diagnostic for e.g., 'touch /' (assuming
- we don't own / or have write access to it).  On Solaris 5.6,
- and probably other systems, it is EINVAL.  On SunOS4, it's EPERM.  */
-  if (fd == -1 && errno != EISDIR && errno != EINVAL && errno != EPERM)
+  if (fd < 0)
 open_errno = errno;
 }
 
@@ -162,9 +156,10 @@ touch (char const *file)
   t = NULL;
 }
 
-  ok = (fdutimensat (fd, AT_FDCWD, (fd == STDOUT_FILENO ? NULL : file), t,
- (no_dereference && fd == -1) ? AT_SYMLINK_NOFOLLOW : 0)
-== 0);
+  char const *file_opt = fd == STDOUT_FILENO ? NULL : file;
+  int atflag = no_dereference ? AT_SYMLINK_NOFOLLOW : 0;
+  int utime_errno = (fdutimensat (fd, AT_FDCWD, file_opt, t, atflag) == 0
+ ? 0 : errno);
 
   if (fd == STDIN_FILENO)
 {
@@ -177,13 +172,22 @@ touch (char const *file)
   else if (fd == STDOUT_FILENO)
 {
   /* Do not diagnose "touch -c - >&-".  */
-  if (!ok && errno == EBADF && no_create)
+  if (utime_errno == EBADF && no_create)
 return true;
 }
 
-  if (!ok)
+  if (utime_errno != 0)
 {
-  if (open_errno)
+  /* Don't diagnose with open_errno if FILE is a directory, as that
+ would give a bogus diagnostic for e.g., 'touch /' (assuming we
+ don't own / or have write access).  On Solaris 10 and probably
+ other systems, opening a directory like "." fails with EINVAL.
+ (On SunOS 4 it was EPERM but that's obsolete.)  */
+  struct stat st;
+  if (open_errno
+  && ! (open_errno == EISDIR
+|| (open_errno == EINVAL
+&& stat (file, ) == 0 && S_ISDIR (st.st_mode
 {
   /* The wording of this diagnostic should cover at least two cases:
  - the file does not exist, but the parent directory is unwritable
@@ -193,9 +197,9 @@ touch (char const *file)
 }
   else
 {
-  if (no_create && errno == ENOENT)
+  if (no_create && utime_errno == ENOENT)
 return true;
-  error (0, errno, _("setting times of %s"), quoteaf (file));
+  error (0, utime_errno, _("setting times of %s"), quoteaf (file));
 }
   return false;
 }
-- 
2.27.0

bug#48106: bug: touch utility does not handle file create error properly

[Roland]

hello,

touch utility telling weird error on file creation on a immutable/ro dir.

apparently, it does not catch/report the first error (EPERM) but only
the second one (ENOENT), when trying to set the time on the non-existing
file.

regards
roland kletzing
sysadmin

root@s900:/tmp# mkdir /tmp/test
root@s900:/tmp# chown 0400 /tmp/test/
root@s900:/tmp# chattr +i /tmp/test
root@s900:/tmp# touch /tmp/test/testfile
touch: setting times of '/tmp/test/testfile': No such file or directory

root@s900:/tmp# strace touch /tmp/test/testfile 2>&1 |grep -i test
execve("/usr/bin/touch", ["touch", "/tmp/test/testfile"], 0x7ffe690abb88
/* 19 vars */) = 0
openat(AT_FDCWD, "/tmp/test/testfile",
O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK, 0666) = -1 EPERM (Operation not
permitted)
utimensat(AT_FDCWD, "/tmp/test/testfile", NULL, 0) = -1 ENOENT (No such
file or directory)
write(2, "setting times of '/tmp/test/test"..., 37setting times of
'/tmp/test/testfile') = 37

# touch  --version
touch (GNU coreutils) 8.30

(on debian 10.9)

bug#48085: date -d greater than 23 years ago gives error invalid date

[Mark Krenz]

  Well it seems that this might actually be related to timezone database
files. My timezone is America/Indianapolis but I noticed when I set the
timezone to America/New_York or UTC that this problem doesn't happen

$ TZ=America/Indianapolis date -d "now - 9001 days"
date: invalid date ‘now - 9001 days’
$ TZ=America/New_York date -d "now - 9001 days"
Thu 05 Sep 1996 07:05:55 PM EDT
$ TZ=UTC date -d "now - 9001 days"
Thu 05 Sep 1996 11:05:59 PM UTC
$ TZ=America/Metlakatla date -d "now - 9001 days"
date: invalid date ‘now - 9001 days’
$ 

I found that last one after trying a for loop in /usr/share/zoneinfo/America

So I'm not sure if this is a problem with coreutils or a change in the
zoneinfo database. Any ideas?

Mark

bug#48085: date -d greater than 23 years ago gives error invalid date

[Mark Krenz]

Further investigating this problem it appears that at least today it
doesn't like going back past September 26th, 1997. But only when the
time delta is specified in years months or days.  You can go back
further if it's specified in total amounts of hours minutes or seconds.


$ date -d "now - 283 months"
Sun 28 Sep 1997 03:42:05 PM EST
$ date -d "now - 284 months"
date: invalid date ‘now - 284 months’

$ date -d "now - 283 months - 2 days"
Fri 26 Sep 1997 03:42:31 PM EST
$ date -d "now - 283 months - 3 days"
date: invalid date ‘now - 283 months - 3 days’

$ date -d "now - 8615 days"
Fri Sep 26 03:52:30 PM EST 1997
$ date -d "now - 8616 days"
date: invalid date ‘now - 8616 days’


$ date -d "now - 206804 hours"
Wed Sep 24 07:54:15 PM EST 1997

$ date -d "now - 12408240 minutes"
Wed Sep 24 08:03:50 PM EST 1997

$ date -d "now - 74459 seconds"
Tue Sep 23 05:20:23 PM EST 1997


I don't see anything special about Sept 25th, 1997 in terms of it's
numeric value:

$ date -d "1997-09-25" +%s
875163600

Or the delta from now to then.

8615*86400 = 744336000

Very weird. I'll be curious to see what turns out to be the problem.  I
also found a system I'm running that has coreutils 8.30 and it did not
have the problem, so that narrows the gap a bit.

Mark

bug#48085: date -d greater than 23 years ago gives error invalid date

[Mark Krenz]

 
I ran the following expecting it to provide me with the date 35 years
ago

  date -d "now - 35 years"

Instead I received the error:

  date: invalid date ‘now - 35 years’

Testing it further I found that the break point is at 24 years:

$ date --version
date (GNU coreutils) 8.32
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David MacKenzie.
$ date -d "now - 23 years"
Tue Apr 28 03:20:37 PM EST 1998
$ date -d "now - 24 years"
date: invalid date ‘now - 24 years’
$

I compiled from the latest coreutils source and found it to have
the same issue:

$ cd coreutils/src/
$ ./date --version
date (GNU coreutils) 8.32.143-62a7c
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David MacKenzie.
$ date "now - 23 years"
date: invalid date ‘now - 23 years’
$ date -d "now - 23 years"
Tue Apr 28 03:21:09 PM EST 1998
$ date -d "now - 24 years"
date: invalid date ‘now - 24 years’
$


I found that this did work on a system running coreutils 8.23 so
something seems to have broken since then. These are all Linux systems
that I've tried this on. The system I tested on was a fresh Ubuntu 21.04
VM.

Linux ubuntu2104 5.11.0-16-generic #17-Ubuntu SMP Wed Apr 14 20:12:43 UTC 2021 
x86_64 x86_64 x86_64 GNU/Linux

Thanks,
Mark
 

bug#44959: date error message should say -I

[Bernhard Voelker]

Hi Padraig,

On 11/30/20 10:31 PM, Pádraig Brady wrote:
> For my reference, if we were to give explicit diagnosis of the leading '='.
> we would need to update xstrtol_fatal, XARGMATCH, operand2sig, set_fields, ...

I'd also rather keep it like it is, but if we change something:
we could advance past the '=' character in the option arg value
... at least in the case where only enumeration or numeric values
are expected (which obviously aren't too many).

Have a nice day,
Berny

bug#44959: date error message should say -I

[Pádraig Brady]

On 30/11/2020 17:22, Pádraig Brady wrote:

On 30/11/2020 15:21, 積丹尼 Dan Jacobson wrote:

Well OK, but when and when not to use the "=" is not revealed by the
otherwise detailed error messages. So unless the user checks the manual,
they will never "get it".


If we were to recognize "-I seconds",
it should just be for diagnostic help.
I.e. we should minimize the combinations of valid inputs,
for compatibility, consistency, and simplicity.

I'll have a look at improving diagnostics in this area.


This is one of the reasons we avoid args to short options,
and new short options in general.
Optional args to short options are rare in coreutils:

  $ grep -- '-[[:alpha:]]\[[A-Z]' man/*.1 | sed 's/,.*//'
  man/date.1:\fB\-I[FMT]\fR
  man/od.1:\fB\-w[BYTES]\fR
  man/pr.1:\fB\-e[CHAR[WIDTH]]\fR
  man/pr.1:\fB\-i[CHAR[WIDTH]]\fR
  man/pr.1:\fB\-n[SEP[DIGITS]]\fR
  man/pr.1:\fB\-s[CHAR]\fR
  man/pr.1:\fB\-s[CHAR]\fR turns off line truncation of all 3 column
  man/pr.1:\fB\-S[STRING]\fR

Non option args to short options as less rare:

  $ grep 'B\\-[^\].*=' man/*.1

For my reference, if we were to give explicit diagnosis of the leading '='.
we would need to update xstrtol_fatal, XARGMATCH, operand2sig, set_fields, ...

cheers,
Pádraig

bug#44959: date error message should say -I

[Pádraig Brady]

On 30/11/2020 15:21, 積丹尼 Dan Jacobson wrote:

Well OK, but when and when not to use the "=" is not revealed by the
otherwise detailed error messages. So unless the user checks the manual,
they will never "get it".


If we were to recognize "-I seconds",
it should just be for diagnostic help.
I.e. we should minimize the combinations of valid inputs,
for compatibility, consistency, and simplicity.

I'll have a look at improving diagnostics in this area.

cheers,
Pádraig

bug#44959: date error message should say -I

[積丹尼 Dan Jacobson]

Well OK, but when and when not to use the "=" is not revealed by the
otherwise detailed error messages. So unless the user checks the manual,
they will never "get it".

bug#44959: date error message should say -I

[Chris Elvidge]

On 30/11/2020 01:40 pm, Bernhard Voelker wrote:

On 11/30/20 2:13 PM, 積丹尼 Dan Jacobson wrote:

$ date -I=seconds
date: invalid argument ‘=seconds’ for ‘--iso-8601’


Hmm, first of all, 'date' 8.32 outputs more than the above:

   $ date -I=seconds
   date: invalid argument '=seconds' for '--iso-8601'
   Valid arguments are:
 - 'hours'
 - 'minutes'
 - 'date'
 - 'seconds'
 - 'ns'
   Try 'date --help' for more information.


Hey, that is a valid argument for --iso-8601. (But not for -I, so say
that instead.)

...

date (GNU coreutils) 8.32



From the above error message and from the --help output, one can see that

the -I option does not require the argument to be appended with "=FMT" but
just "FMT":

   $ date --help | grep -- -I
 -I[FMT], --iso-8601[=FMT]  output date/time in ISO 8601 format.

So, I'd say 'date' works as expected:

   $ date -Iseconds
   2020-11-30T14:38:35+01:00

Have a nice day,
Berny






Is -I the only option that doesn't accept a space separator between it 
and its argument? Is that because it doesn't require an argument?


Could/Should the argument after -I be parsed and used if it is one of 
date hours minutes seconds ns? (Could it also parse for mins secs?) But 
used as a separate option if not parsed as an argument?


Is this too difficult?

Cheers

--

Chris Elvidge

bug#44959: date error message should say -I

[Bernhard Voelker]

On 11/30/20 2:13 PM, 積丹尼 Dan Jacobson wrote:
> $ date -I=seconds
> date: invalid argument ‘=seconds’ for ‘--iso-8601’

Hmm, first of all, 'date' 8.32 outputs more than the above:

  $ date -I=seconds
  date: invalid argument '=seconds' for '--iso-8601'
  Valid arguments are:
- 'hours'
- 'minutes'
- 'date'
- 'seconds'
- 'ns'
  Try 'date --help' for more information.

> Hey, that is a valid argument for --iso-8601. (But not for -I, so say
> that instead.)
...
> date (GNU coreutils) 8.32

>From the above error message and from the --help output, one can see that
the -I option does not require the argument to be appended with "=FMT" but
just "FMT":

  $ date --help | grep -- -I
-I[FMT], --iso-8601[=FMT]  output date/time in ISO 8601 format.

So, I'd say 'date' works as expected:

  $ date -Iseconds
  2020-11-30T14:38:35+01:00

Have a nice day,
Berny

bug#44959: date error message should say -I

[積丹尼 Dan Jacobson]

$ date -I=seconds
date: invalid argument ‘=seconds’ for ‘--iso-8601’

Hey, that is a valid argument for --iso-8601. (But not for -I, so say
that instead.)

Here is a real invalid argument:

$ date --iso-8601=secondsz
date: invalid argument ‘secondsz’ for ‘--iso-8601’

date (GNU coreutils) 8.32

bug#44865: date recalculation error

[Rainer M. Canavan]

Ruder Laplace  wrote:
> Greetings,
> 
> I think I catched a bug related to the day-light saving gap:
> *uname -a ; date ; date -d "2020/06/01 10:00:00 +1 hours"*
> Linux  4.19.0-8-amd64 #1 SMP Debian 4.19.98-1 (2020-01-26) x86_64
> GNU/Linux
> mié nov 25 10:30:29 CET 2020
> lun jun  1 *12*:00:00 CEST 2020
> 
> As far as I think it should work, the expected result should be: lun jun 1
> *11*:00:00 CEST 2020
> "One hour after 10" is 11, not 12.


You can check how date interprets your string using --debug:

$ date -d "2020/06/01 11:00:00 +1 hour" --debug 
date: warning: value 2020 has 4 digits. Assuming /MM/DD
date: parsed date part: (Y-M-D) 2020-06-01
date: parsed time part: 11:00:00 UTC+01
date: parsed relative part: +1 hour(s)
date: input timezone: parsed date/time string (+01)
date: using specified time as starting value: '11:00:00'
date: starting date/time: '(Y-M-D) 2020-06-01 11:00:00 TZ=+01'
date: '(Y-M-D) 2020-06-01 11:00:00 TZ=+01' = 1591005600 epoch-seconds
date: after time adjustment (+1 hours, +0 minutes, +0 seconds, +0 ns),
date: new time = 1591009200 epoch-seconds
date: timezone: system default
date: final: 1591009200.0 (epoch-seconds)
date: final: (Y-M-D) 2020-06-01 11:00:00 (UTC)
date: final: (Y-M-D) 2020-06-01 13:00:00 (UTC+02)
Mo 1. Jun 13:00:00 CEST 2020


As you can see, it assumes that the "+1" indicates the timezone, which
is 1 hour behind your local zone, thus 11:00 there would actually be 12:00
in your time zone. The "hour" alone is then used as a +1 hour adjustment,
resulting in 13:00 CEST. Commands that work as you expected:

$ date -d "2020/06/01 11:00:00 1 hour" --debug
$ date -d "2020/06/01 11:00:00 +1 +1 hour" --debug
$ date -d "2020/06/01 11:00:00 CEST +1 hour" --debug
$ date -d "+1 hour 2020/06/01 11:00:00" --debug

rainer

bug#44865: date recalculation error

[Ruder Laplace]

Greetings,

I think I catched a bug related to the day-light saving gap:
*uname -a ; date ; date -d "2020/06/01 10:00:00 +1 hours"*
Linux  4.19.0-8-amd64 #1 SMP Debian 4.19.98-1 (2020-01-26) x86_64
GNU/Linux
mié nov 25 10:30:29 CET 2020
lun jun  1 *12*:00:00 CEST 2020

As far as I think it should work, the expected result should be: lun jun 1
*11*:00:00 CEST 2020
"One hour after 10" is 11, not 12.

I'm not sure if it has something to do to be right now in UTC+1 and the
other time un UTC+2, but I don't remember having any trouble while in DL
saving while on UTC+2.

To me, the intuitive way is the one the program worries about whether DL
saving was/will be ON on the specified time.

*date --version*
date (GNU coreutils) 8.30
Copyright (C) 2018 Free Software Foundation, Inc.

*lsb_release -a*
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux 10 (buster)
Release:10
Codename:   buster

Thanks for your time,
Ruder Laplace.

bug#44763: Error when 'make'ing latest version of coreutils

[Paul Eggert]

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 
$outfiles/out_commit.1.txt


I suggest doing the bootstrap after this 'git commit', not earlier.


Because of the abovementioned patches, you should no longer need to do the 
following steps:



# Berny's addition
git clean -xdfq && ./bootstrap 2>&1 | tee -a $outfiles/out_bootstrap.2.txt

./configure 2>&1 | tee -a $outfiles/out_configure.1.txt

# do edit to make make work
# Akim's change - make it expect a long not a long long
sed -i -e '2301s/%"PRIdMAX"/%ld/' lib/parse-datetime.y
sed -n 2301p lib/parse-datetime.y

# do three edits to make make check work
# put 'return NULL;' back before '/*NOTREACHED*/' # explained by Berny
sed -i -e '184s#\(/\*NOTREACHED\*/\)#return NULL; \1#' 
gnulib/tests/test-nl_langinfo-mt.c

sed -n 184p gnulib/tests/test-nl_langinfo-mt.c
sed -i -e '94s#\(/\*NOTREACHED\*/\)#return NULL; \1#' 
gnulib/tests/test-setlocale_null-mt-all.c

sed -n 94p gnulib/tests/test-setlocale_null-mt-all.c
sed -i -e '94s#\(/\*NOTREACHED\*/\)#return NULL; \1#' 
gnulib/tests/test-setlocale_null-mt-one.c

sed -n 94p gnulib/tests/test-setlocale_null-mt-one.c

# pause here to make sure edits done properly
read -p "Press return to continue" junk

bug#44763: Error when 'make'ing latest version of coreutils

[Paul Eggert]

On 11/21/20 6:37 AM, Chris Elvidge wrote:

parse-datetime.y: In function 'parse_datetime2':
parse-datetime.y:2301:27: error: format '%lld' expects argument of type 'long 
long int', but argument 2 has type 'time_t {aka long int}' [-Werror=format=]


That's due to a typo that I recently introduced to parse-datetime.y. Thanks for 
reporting it. (I didn't observe the problem since I tested on hosts with 64-bit 
time_t, not 32-bit.) I installed the attached patch into Gnulib and propagated 
this into Coreutils.
>From fdf0468198631a456406edc09983972edb8fa5c4 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Sat, 21 Nov 2020 19:04:10 -0800
Subject: [PATCH] parse-datetime: fix printf format typo

* lib/parse-datetime.y (parse_datetime2): Fix format typo in
previous patch to this file.  Problem reported by Chris Elvidge in
<https://bugs.gnu.org/44763#32>.
---
 ChangeLog| 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-datetime.y (parse_datetime2): Fix format typo in
+	previous patch to this file.  Problem reported by Chris Elvidge in
+	<https://bugs.gnu.org/44763#32>.
+
 	setlocale-null-tests: work around GCC bug 44511
 	* tests/test-setlocale_null-mt-all.c:
 	* tests/test-setlocale_null-mt-one.c:
diff --git a/lib/parse-datetime.y b/lib/parse-datetime.y
index 44ae90350..e8ed691c8 100644
--- a/lib/parse-datetime.y
+++ b/lib/parse-datetime.y
@@ -2298,7 +2298,8 @@ parse_datetime2 (struct timespec *result, char const *p,
   "%+"PRIdMAX" seconds, %+d ns),\n"),
 pc.rel.hour, pc.rel.minutes, pc.rel.seconds,
 pc.rel.ns);
-dbg_printf (_("new time = %"PRIdMAX" epoch-seconds\n"), t4);
+intmax_t t4i = t4;
+dbg_printf (_("new time = %"PRIdMAX" epoch-seconds\n"), t4i);
 
 /* Warn about crossing DST due to time adjustment.
Example: https://bugs.gnu.org/8357
-- 
2.27.0

bug#44763: Error when 'make'ing latest version of coreutils

[Paul Eggert]

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.

bug#44763: Error when 'make'ing latest version of coreutils

[Chris Elvidge]

Finally! Got make, make _version, make check, make install finished.

Here's my instruction file, run from Downloads directory (sorry about 
the wordwrap, should be obvious though)


outfiles="$(pwd)/outfiles"
[ -d "$outfiles" ] || mkdir -p $outfiles

git clone git://git.sv.gnu.org/coreutils 2>&1 | tee -a 
$outfles/out_git_clone.1.txt

cd coreutils

./bootstrap 2>&1 | tee -a $outfiles/out_bootstrap.1.txt
git submodule foreach git pull origin master 2>&1 | tee -a 
$outfiles/out_submodule.1.txt


# these should changed to reflect user
git config --global user.email "celvidge...@gmail.com"
git config --global user.name "Chris Elvidge"

git commit -m 'build: update gnulib submodule to latest' gnulib 2>&1 | 
tee -a $outfiles/out_commit.1.txt


# Berny's addition
git clean -xdfq && ./bootstrap 2>&1 | tee -a $outfiles/out_bootstrap.2.txt

./configure 2>&1 | tee -a $outfiles/out_configure.1.txt

# do edit to make make work
# Akim's change - make it expect a long not a long long
sed -i -e '2301s/%"PRIdMAX"/%ld/' lib/parse-datetime.y
sed -n 2301p lib/parse-datetime.y

# do three edits to make make check work
# put 'return NULL;' back before '/*NOTREACHED*/' # explained by Berny
sed -i -e '184s#\(/\*NOTREACHED\*/\)#return NULL; \1#' 
gnulib/tests/test-nl_langinfo-mt.c

sed -n 184p gnulib/tests/test-nl_langinfo-mt.c
sed -i -e '94s#\(/\*NOTREACHED\*/\)#return NULL; \1#' 
gnulib/tests/test-setlocale_null-mt-all.c

sed -n 94p gnulib/tests/test-setlocale_null-mt-all.c
sed -i -e '94s#\(/\*NOTREACHED\*/\)#return NULL; \1#' 
gnulib/tests/test-setlocale_null-mt-one.c

sed -n 94p gnulib/tests/test-setlocale_null-mt-one.c

# pause here to make sure edits done properly
read -p "Press return to continue" junk

make 2>&1 | tee -a $outfiles/out_make.1.txt

# install complains if this not done
make _version | tee -a $outfiles/out_make.2.txt

make check | tee -a $outfiles/out_make.3.txt


Cheers all!!


On 21/11/2020 09:16 pm, Bernhard Voelker wrote:

[adding Paul]

On 11/21/20 8:54 PM, Chris Elvidge wrote:

    CC   test-nl_langinfo-mt.o
test-nl_langinfo-mt.c: In function 'threadN_func':
test-nl_langinfo-mt.c:185:1: error: no return statement in function
returning non-void [-Werror=return-type]
   }
   ^
cc1: all warnings being treated as errors
Makefile:6586: recipe for target 'test-nl_langinfo-mt.o' failed


I see the same with gcc-10.2.1 here.

It happens since:
   https://git.sv.gnu.org/cgit/gnulib.git/commit/?id=bd90572c031

Paul removed the return statement because Sun C 5.9 complains about it.

   static void *
   threadN_func (void *arg)
   {
 for (;;)
   {
 nl_langinfo (CODESET);   /* LC_CTYPE *//* locale charmap */
 nl_langinfo (AM_STR);/* LC_TIME */ /* locale -k am_pm */
 nl_langinfo (PM_STR);/* LC_TIME */ /* locale -k am_pm */
 nl_langinfo (DAY_2); /* LC_TIME */ /* locale -k day */
 nl_langinfo (DAY_5); /* LC_TIME */ /* locale -k day */
 nl_langinfo (ALTMON_2);  /* LC_TIME */ /* locale -k alt_mon */
 nl_langinfo (ALTMON_9);  /* LC_TIME */ /* locale -k alt_mon */
 nl_langinfo (CRNCYSTR);  /* LC_MONETARY */ /* locale -k 
currency_symbol */
 nl_langinfo (RADIXCHAR); /* LC_NUMERIC */  /* locale -k decimal_point 
*/
 nl_langinfo (THOUSEP);   /* LC_NUMERIC */  /* locale -k thousands_sep 
*/
   }

 /*NOTREACHED*/
-   return NULL;
   }

How to fix?

Have a nice day,
Berny




--

Chris Elvidge

5 Ebor Park, Appleton Roebuck, York.  YO23 7DZ.
Tel (Mob): +447443472958 mailto:celvi...@outlook.com

Calle Padre Raimundo Codesal 1, Vélez-Málaga, 29700, España

bug#44763: Error when 'make'ing latest version of coreutils

[Bernhard Voelker]

[adding Paul]

On 11/21/20 8:54 PM, Chris Elvidge wrote:
>CC   test-nl_langinfo-mt.o
> test-nl_langinfo-mt.c: In function 'threadN_func':
> test-nl_langinfo-mt.c:185:1: error: no return statement in function 
> returning non-void [-Werror=return-type]
>   }
>   ^
> cc1: all warnings being treated as errors
> Makefile:6586: recipe for target 'test-nl_langinfo-mt.o' failed

I see the same with gcc-10.2.1 here.

It happens since:
  https://git.sv.gnu.org/cgit/gnulib.git/commit/?id=bd90572c031

Paul removed the return statement because Sun C 5.9 complains about it.

  static void *
  threadN_func (void *arg)
  {
for (;;)
  {
nl_langinfo (CODESET);   /* LC_CTYPE *//* locale charmap */
nl_langinfo (AM_STR);/* LC_TIME */ /* locale -k am_pm */
nl_langinfo (PM_STR);/* LC_TIME */ /* locale -k am_pm */
nl_langinfo (DAY_2); /* LC_TIME */ /* locale -k day */
nl_langinfo (DAY_5); /* LC_TIME */ /* locale -k day */
nl_langinfo (ALTMON_2);  /* LC_TIME */ /* locale -k alt_mon */
nl_langinfo (ALTMON_9);  /* LC_TIME */ /* locale -k alt_mon */
nl_langinfo (CRNCYSTR);  /* LC_MONETARY */ /* locale -k currency_symbol 
*/
nl_langinfo (RADIXCHAR); /* LC_NUMERIC */  /* locale -k decimal_point */
nl_langinfo (THOUSEP);   /* LC_NUMERIC */  /* locale -k thousands_sep */
  }

/*NOTREACHED*/
-   return NULL;
  }

How to fix?

Have a nice day,
Berny

bug#44763: Error when 'make'ing latest version of coreutils

[Chris Elvidge]

OK All. Thanks for all the help.
Whether the bison (3.0.2 -> 3.7) upgrade was needed seems to be a moot 
point.
Berny's mod to the bootstrap process (adding a step just before 
configure 'git clean -xdfq && ./bootstrap') got over the first error.

Akim's mod to lib/parse-datetime.y (below) cured the second error.

make-check

Testsuite summary for GNU coreutils 8.32.74-d889b

# TOTAL: 622
# PASS:  513
# SKIP:  109
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0


but then:

  CC   test-nl_langinfo-mt.o
test-nl_langinfo-mt.c: In function 'threadN_func':
test-nl_langinfo-mt.c:185:1: error: no return statement in function 
returning non-void [-Werror=return-type]

 }
 ^
cc1: all warnings being treated as errors
Makefile:6586: recipe for target 'test-nl_langinfo-mt.o' failed
make[5]: *** [test-nl_langinfo-mt.o] Error 1
make[5]: Leaving directory '/home/chris/Downloads/coreutils/gnulib-tests'
Makefile:9494: recipe for target 'check-am' failed
make[4]: *** [check-am] Error 2
make[4]: Leaving directory '/home/chris/Downloads/coreutils/gnulib-tests'
Makefile:6691: recipe for target 'check-recursive' failed
make[3]: *** [check-recursive] Error 1
make[3]: Leaving directory '/home/chris/Downloads/coreutils/gnulib-tests'
Makefile:9497: recipe for target 'check' failed
make[2]: *** [check] Error 2
make[2]: Leaving directory '/home/chris/Downloads/coreutils/gnulib-tests'
Makefile:12479: recipe for target 'check-recursive' failed
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory '/home/chris/Downloads/coreutils'
Makefile:12956: recipe for target 'check' failed
make: *** [check] Error 2

As I didn't really care about the tests I did sudo make install which 
said the version number was out-of-date ans asked for make _version.

I did that and then sudo make install again.

It all seems to have worked. --version reports 8.32.74-d889b-dirty

Thanks again
Cheers

On 21/11/2020 06:14 pm, Akim Demaille wrote:

Hi Chris,

I saw nothing suspicious about Bison in the logs you sent.


Le 21 nov. 2020 à 18:33, Chris Elvidge  a écrit :

  CC   lib/parse-datetime.o
In file included from lib/gettext.h:26:0,
 from parse-datetime.y:71:
parse-datetime.y: In function 'parse_datetime2':
parse-datetime.y:2301:27: error: format '%lld' expects argument of type 'long 
long int', but argument 2 has type 'time_t {aka long int}' [-Werror=format=]
parse-datetime.y:2301:25: note: in expansion of macro '_'


This is the only error I spotted, and that corresponds to:

   2296 dbg_printf (_("after time adjustment (%+"PRIdMAX" hours, "
   2297   "%+"PRIdMAX" minutes, "
   2298   "%+"PRIdMAX" seconds, %+d ns),\n"),
   2299 pc.rel.hour, pc.rel.minutes, pc.rel.seconds,
   2300 pc.rel.ns);
   2301 dbg_printf (_("new time = %"PRIdMAX" epoch-seconds\n"), 
t4);

with

 time_t t4;

so it appears we "only" have a portability issue where gnulib
believes %PRIdMAX is ok for time_t, but it is not.

The other guys (in the previous gdb_printf) are intmax_t:

/* Relative times.  */
typedef struct
{
   /* Relative year, month, day, hour, minutes, seconds, and nanoseconds.  */
   intmax_t year;
   intmax_t month;
   intmax_t day;
   intmax_t hour;
   intmax_t minutes;
   intmax_t seconds;
   int ns;
} relative_time;

I have no idea what is the best course of action to fix the error
(a cast?  A configure check to fight the right printf format?  Changing
the type of t4?), but Chris, if you just want to build, then simply
change 2301 into

dbg_printf (_("new time = %ld epoch-seconds\n"), t4);

That should do it.

Cheers!




--

Chris Elvidge

bug#44763: Error when 'make'ing latest version of coreutils

[Akim Demaille]

Hi Chris,

I saw nothing suspicious about Bison in the logs you sent.

> Le 21 nov. 2020 à 18:33, Chris Elvidge  a écrit :
> 
>  CC   lib/parse-datetime.o
> In file included from lib/gettext.h:26:0,
> from parse-datetime.y:71:
> parse-datetime.y: In function 'parse_datetime2':
> parse-datetime.y:2301:27: error: format '%lld' expects argument of type 'long 
> long int', but argument 2 has type 'time_t {aka long int}' [-Werror=format=]
> parse-datetime.y:2301:25: note: in expansion of macro '_'

This is the only error I spotted, and that corresponds to:

  2296  dbg_printf (_("after time adjustment (%+"PRIdMAX" hours, "
  2297"%+"PRIdMAX" minutes, "
  2298"%+"PRIdMAX" seconds, %+d ns),\n"),
  2299  pc.rel.hour, pc.rel.minutes, pc.rel.seconds,
  2300  pc.rel.ns);
  2301  dbg_printf (_("new time = %"PRIdMAX" epoch-seconds\n"), 
t4);

with

time_t t4;

so it appears we "only" have a portability issue where gnulib
believes %PRIdMAX is ok for time_t, but it is not.

The other guys (in the previous gdb_printf) are intmax_t:

/* Relative times.  */
typedef struct
{
  /* Relative year, month, day, hour, minutes, seconds, and nanoseconds.  */
  intmax_t year;
  intmax_t month;
  intmax_t day;
  intmax_t hour;
  intmax_t minutes;
  intmax_t seconds;
  int ns;
} relative_time;

I have no idea what is the best course of action to fix the error
(a cast?  A configure check to fight the right printf format?  Changing
the type of t4?), but Chris, if you just want to build, then simply
change 2301 into

dbg_printf (_("new time = %ld epoch-seconds\n"), t4);

That should do it.

Cheers!

bug#44763: Error when 'make'ing latest version of coreutils

[Chris Elvidge]

These are the commands as run:

git clone git://git.sv.gnu.org/coreutils
cd coreutils
./bootstrap | tee -a out_bootstrap.1
git submodule foreach git pull origin master
git config --global user.email "celvidge...@gmail.com"
git config --global user.name "Chris Elvidge"
git commit -m 'build: update gnulib submodule to latest' gnulib
git clean -xdfq && ./bootstrap | tee -a out_bootstrap.2
./configure  TIME_T_32_BIT_OK=yes | tee -a out_configure.1

I've got the output of the second bootstrap run (git clean deleted the 
first one, I think) and the configure run.

However I've only got the error message at the end on the make run.

  CC   lib/parse-datetime.o
In file included from lib/gettext.h:26:0,
 from parse-datetime.y:71:
parse-datetime.y: In function 'parse_datetime2':
parse-datetime.y:2301:27: error: format '%lld' expects argument of type 
'long long int', but argument 2 has type 'time_t {aka long int}' 
[-Werror=format=]

parse-datetime.y:2301:25: note: in expansion of macro '_'
cc1: all warnings being treated as errors
Makefile:9842: recipe for target 'lib/parse-datetime.o' failed
make[2]: *** [lib/parse-datetime.o] Error 1
make[2]: Leaving directory '/home/chris/Downloads/coreutils'
Makefile:12479: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/chris/Downloads/coreutils'
Makefile:6581: recipe for target 'all' failed
make: *** [all] Error 2

I'll send the 30K gzipped file direct to Akim separately, if that's OK.

Cheers

On 21/11/2020 04:53 pm, Akim Demaille wrote:

Hi all,


Le 20 nov. 2020 à 16:48, Pádraig Brady  a écrit :

See also https://bugs.gnu.org/44739


There, I just read this:


I found that I needed to upgrade to Bison v3.7.4 to avoid a build error
in stdlib.h where @GNULIB_POSIX_MEMALIGN@ has not been converted by
Bison. The check in your bootstrap program allows for an older version
of Bison to be used which fails to do the necessary conversion.


which is not correct.  Bison does not perform any transformation
on @FOO@ at all.  This is completely unrelated to it.  What would
be most useful is to get the generated files and see what they
look like.

Also, I might have missed messages, but I would like to see a
plain copy-paste of the terminal where I can see exactly what
commands were run, and what the tools reported.

Cheers!




--

Chris Elvidge

bug#44763: Error when 'make'ing latest version of coreutils

[Akim Demaille]

Hi all,

> Le 20 nov. 2020 à 16:48, Pádraig Brady  a écrit :
> 
> See also https://bugs.gnu.org/44739

There, I just read this:

>> I found that I needed to upgrade to Bison v3.7.4 to avoid a build error 
>> in stdlib.h where @GNULIB_POSIX_MEMALIGN@ has not been converted by 
>> Bison. The check in your bootstrap program allows for an older version 
>> of Bison to be used which fails to do the necessary conversion.

which is not correct.  Bison does not perform any transformation
on @FOO@ at all.  This is completely unrelated to it.  What would
be most useful is to get the generated files and see what they
look like.

Also, I might have missed messages, but I would like to see a
plain copy-paste of the terminal where I can see exactly what
commands were run, and what the tools reported.

Cheers!

bug#44763: Error when 'make'ing latest version of coreutils

[Chris Elvidge]

Still no luck. Same error in parse-datetime.y
Cheers

On 21/11/2020 01:17 pm, Bernhard Voelker wrote:

On 11/20/20 5:38 PM, Chris Elvidge wrote:

Reran the whole thing from git clone etc.
(
git clone git://git.sv.gnu.org/coreutils
cd coreutils
./bootstrap
git submodule foreach git pull origin master
git config --global user.email "celvidge...@gmail.com"
git config --global user.name "Chris Elvidge"
git commit -m 'build: update gnulib submodule to latest' gnulib
./configure
)


In general it is advised that one has to

  git clean -xdfq \
   && ./bootstrap

again after a gnulib update.

Have a nice day,
Berny




--

Chris Elvidge

5 Ebor Park, Appleton Roebuck, York.  YO23 7DZ.
Tel (Mob): +447443472958 mailto:celvi...@outlook.com

Calle Padre Raimundo Codesal 1, Vélez-Málaga, 29700, España

bug#44763: Error when 'make'ing latest version of coreutils

[Chris Elvidge]

Well, that got me a bit further. Thanks.
Now the error from 'make' is:

  CC   lib/parse-datetime.o
In file included from lib/gettext.h:26:0,
 from parse-datetime.y:71:
parse-datetime.y: In function 'parse_datetime2':
parse-datetime.y:2301:27: error: format '%lld' expects argument of type 
'long long int', but argument 2 has type 'time_t {aka long int}' 
[-Werror=format=]

parse-datetime.y:2301:25: note: in expansion of macro '_'
cc1: all warnings being treated as errors
Makefile:9842: recipe for target 'lib/parse-datetime.o' failed
make[2]: *** [lib/parse-datetime.o] Error 1
make[2]: Leaving directory '/home/chris/Downloads/coreutils'
Makefile:12479: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/chris/Downloads/coreutils'
Makefile:6581: recipe for target 'all' failed
make: *** [all] Error 2

I tried ./configure TIME_T_32_BIT_OK=yes - didn't make any difference.

I'm going to try again from scratch.
I'll let you know.

On 21/11/2020 01:17 pm, Bernhard Voelker wrote:

On 11/20/20 5:38 PM, Chris Elvidge wrote:

Reran the whole thing from git clone etc.
(
git clone git://git.sv.gnu.org/coreutils
cd coreutils
./bootstrap
git submodule foreach git pull origin master
git config --global user.email "celvidge...@gmail.com"
git config --global user.name "Chris Elvidge"
git commit -m 'build: update gnulib submodule to latest' gnulib
./configure
)


In general it is advised that one has to

  git clean -xdfq \
   && ./bootstrap

again after a gnulib update.

Have a nice day,
Berny




--

Chris Elvidge

5 Ebor Park, Appleton Roebuck, York.  YO23 7DZ.
Tel (Mob): +447443472958 mailto:celvi...@outlook.com

Calle Padre Raimundo Codesal 1, Vélez-Málaga, 29700, España

bug#44763: Error when 'make'ing latest version of coreutils

[Bernhard Voelker]

On 11/20/20 5:38 PM, Chris Elvidge wrote:
> Reran the whole thing from git clone etc.
> (
> git clone git://git.sv.gnu.org/coreutils
> cd coreutils
> ./bootstrap
> git submodule foreach git pull origin master
> git config --global user.email "celvidge...@gmail.com"
> git config --global user.name "Chris Elvidge"
> git commit -m 'build: update gnulib submodule to latest' gnulib
> ./configure
> )

In general it is advised that one has to

 git clean -xdfq \
  && ./bootstrap

again after a gnulib update.

Have a nice day,
Berny

bug#44763: Error when 'make'ing latest version of coreutils

[Pádraig Brady]

On 21/11/2020 07:01, Akim Demaille wrote:

Hi guys,


Le 21 nov. 2020 à 07:35, Akim Demaille  a écrit :

Hi Pádraig,

Just in case:

$ for i in /usr/local/stow/bison-3.*


I had forgotten that there is a 2.3 sitting on my system, and indeed:

$ /usr/bin/bison gnulib/lib/parse-datetime.y
gnulib/lib/parse-datetime.y:555.9-16: syntax error, unexpected identifier, 
expecting string

It chokes on `%define api.pure`.

According to NEWS, this syntax was introduced in 2.4 (2008-11-02).

I have tried to install 2.7 on my system, but I can't (because of
portability issues of vasnprintf that were not covered by gnulib at
that time).  I cannot even install 3.0.


Thanks a lot for checking.
The info in https://bugs.gnu.org/44739 must be incorrect,
and we've two counter checks to it now.

cheers,
Pádraig

bug#44763: Error when 'make'ing latest version of coreutils

[Akim Demaille]

Hi guys,

> Le 21 nov. 2020 à 07:35, Akim Demaille  a écrit :
> 
> Hi Pádraig,
> 
> Just in case:
> 
> $ for i in /usr/local/stow/bison-3.*

I had forgotten that there is a 2.3 sitting on my system, and indeed:

$ /usr/bin/bison gnulib/lib/parse-datetime.y
gnulib/lib/parse-datetime.y:555.9-16: syntax error, unexpected identifier, 
expecting string

It chokes on `%define api.pure`.

According to NEWS, this syntax was introduced in 2.4 (2008-11-02).

I have tried to install 2.7 on my system, but I can't (because of
portability issues of vasnprintf that were not covered by gnulib at
that time).  I cannot even install 3.0.

Cheers!

bug#44763: Error when 'make'ing latest version of coreutils

[Akim Demaille]

Hi Pádraig,

> Le 20 nov. 2020 à 15:47, Pádraig Brady  a écrit :
> 
> On 20/11/2020 14:19, Chris Elvidge wrote:
>> I keep getting
>> ./lib/stdlib.h:695:5: error: token "@" is not valid in preprocessor
>> expressions
>>   #if @GNULIB_ALIGNED_ALLOC@
>>   ^
>> ./lib/stdlib.h:1059:5: error: token "@" is not valid in preprocessor
>> expressions
>>   #if @GNULIB_POSIX_MEMALIGN@
> 
> Please update bison to >= 3.5.
> I don't know what the exact new requirement is,
> but will update bootstrap.conf to check that very soon.
> 
> Akim do you know the min bison version
> now required by the latest gnulib?
> That would spare me some bisecting.

I wasn't aware of any strong dependency such as this one (and I actually
still have not understood what the problem is, and how problems with
AC_SUBST are related to Bison here).

The only I see in gnulib which is a *.y is lib/parse-datetime.y.
And I don't see anything special in it that would require any special
version of Bison.

Just in case:

$ for i in /usr/local/stow/bison-3.*
do
echo "$i..."  
$i/bin/bison lib/parse-datetime.y
done
/usr/local/stow/bison-3.0.5...
/usr/local/stow/bison-3.1...
/usr/local/stow/bison-3.2.4...
/usr/local/stow/bison-3.3.2...
/usr/local/stow/bison-3.4.2...
/usr/local/stow/bison-3.5.4...
/usr/local/stow/bison-3.6.4...
/usr/local/stow/bison-3.7...
/usr/local/stow/bison-3.7.1...
/usr/local/stow/bison-3.7.2...
/usr/local/stow/bison-3.7.3...

I think I have not understood the question, sorry :(  What exactly
happens here?  Is configure properly rerun each time, without cache?
Why are we talking about Bison?

bug#44763: Error when 'make'ing latest version of coreutils

[Pádraig Brady]

On 20/11/2020 15:42, Chris Elvidge wrote:

Updated to bison 3.7; installed in /usr/local/bin
Unfortunately, still the same error
Logged off/on, disabled /usr/bin/bison and yacc, rebooted.
No go.
Thanks.


Did you rerun bootstrap?
What version was /usr/bin/bison ?
See also https://bugs.gnu.org/44739

thanks,
Pádraig

bug#44763: Error when 'make'ing latest version of coreutils

[Chris Elvidge]

Updated to bison 3.7; installed in /usr/local/bin
Unfortunately, still the same error
Logged off/on, disabled /usr/bin/bison and yacc, rebooted.
No go.
Thanks.

On 20/11/2020 02:47 pm, Pádraig Brady wrote:

On 20/11/2020 14:19, Chris Elvidge wrote:

I keep getting

./lib/stdlib.h:695:5: error: token "@" is not valid in preprocessor
expressions
   #if @GNULIB_ALIGNED_ALLOC@
   ^
./lib/stdlib.h:1059:5: error: token "@" is not valid in preprocessor
expressions
   #if @GNULIB_POSIX_MEMALIGN@


Please update bison to >= 3.5.
I don't know what the exact new requirement is,
but will update bootstrap.conf to check that very soon.

Akim do you know the min bison version
now required by the latest gnulib?
That would spare me some bisecting.

thanks,
Pádraig




--

Chris Elvidge

5 Ebor Park, Appleton Roebuck, York.  YO23 7DZ.
Tel (Mob): +447443472958 mailto:celvi...@outlook.com

Calle Padre Raimundo Codesal 1, Vélez-Málaga, 29700, España

bug#44763: Error when 'make'ing latest version of coreutils

[Pádraig Brady]

On 20/11/2020 14:19, Chris Elvidge wrote:

I keep getting

./lib/stdlib.h:695:5: error: token "@" is not valid in preprocessor
expressions
   #if @GNULIB_ALIGNED_ALLOC@
   ^
./lib/stdlib.h:1059:5: error: token "@" is not valid in preprocessor
expressions
   #if @GNULIB_POSIX_MEMALIGN@


Please update bison to >= 3.5.
I don't know what the exact new requirement is,
but will update bootstrap.conf to check that very soon.

Akim do you know the min bison version
now required by the latest gnulib?
That would spare me some bisecting.

thanks,
Pádraig

bug#44763: Error when 'make'ing latest version of coreutils

[Chris Elvidge]

I keep getting

./lib/stdlib.h:695:5: error: token "@" is not valid in preprocessor 
expressions

 #if @GNULIB_ALIGNED_ALLOC@
 ^
./lib/stdlib.h:1059:5: error: token "@" is not valid in preprocessor 
expressions

 #if @GNULIB_POSIX_MEMALIGN@
 ^
when running make in the latest version of coreutils.

Slackware 14.2 : 32-bit : VBox VM

I did:
git clone git://git.sv.gnu.org/coreutils
./bootstrap
git submodule foreach git pull origin master
git config --global user.email "celvidge...@gmail.com"
git config --global user.name "Chris Elvidge"
git commit -m 'build: update gnulib submodule to latest' gnulib
./configure
make

Relevant lines from stdlib.h

'sed -n 690,700p ./lib/stdlib.h'
# endif
#endif


/* Allocate memory with indefinite extent and specified alignment.  */
#if @GNULIB_ALIGNED_ALLOC@
# if @REPLACE_ALIGNED_ALLOC@
#  if !(defined __cplusplus && defined GNULIB_NAMESPACE)
#   undef aligned_alloc
#   define aligned_alloc rpl_aligned_alloc
#  endif

'sed -n 1055,1065p ./lib/stdlib.h'
# define mktemp _mktemp
#endif

/* Allocate memory with indefinite extent and specified alignment.  */
#if @GNULIB_POSIX_MEMALIGN@
# if @REPLACE_POSIX_MEMALIGN@
#  if !(defined __cplusplus && defined GNULIB_NAMESPACE)
#   undef posix_memalign
#   define posix_memalign rpl_posix_memalign
#  endif
_GL_FUNCDECL_RPL (posix_memalign, int,

Can anyone help, please?

--

Chris Elvidge

5 Ebor Park, Appleton Roebuck, York.  YO23 7DZ.
Tel (Mob): +447443472958 mailto:celvi...@outlook.com

Calle Padre Raimundo Codesal 1, Vélez-Málaga, 29700, España

bug#44695: error - GraphClust2 docker

[Paul Eggert]

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 for reporting that. As it happens, the problem was fixed in coreutils 
8.25 (2016-01-20); see:


https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27513

so I'll close the bug report and you should be able to fix the problem by 
upgrading to a more-modern coreutils.

bug#39236: [musl] coreutils cp mishandles error return from lchmod

[Florian Weimer]

* Rich Felker:

> Note that in any case, musl's lchmod/fchmodat is not affected since it
> always refuses to change symlink modes; I did this because I was
> worried that chmod on the magic symlink in /proc might pass through
> not just to the symlink it refers to, but to the symlink target if one
> exists. With current kernel versions it seems that does not happen; is
> it safe to assume it doesn't?

I saw it happen with sshfs over FUSE. 8-/

Yet another reason to put in a check before performing the chmod.

> Further, I've found some inconsistent behavior with ext4: chmod on the
> magic symlink fails with EOPNOTSUPP as in Florian's test, but fchmod
> on the O_PATH fd succeeds and changes the symlink mode. This is with
> 5.4. Cany anyone else confirm this? Is it a problem?

Interesting. Let me update the other thread.

bug#39236: [musl] coreutils cp mishandles error return from lchmod

[Rich Felker]

On Wed, Feb 12, 2020 at 08:05:55AM -0500, Rich Felker wrote:
> On Wed, Feb 12, 2020 at 12:50:19PM +0100, Florian Weimer wrote:
> > * Paul Eggert:
> > 
> > > On 1/22/20 2:05 PM, Rich Felker wrote:
> > >> I think we're approaching a consensus that glibc should fix this too,
> > >> so then it would just be gnulib matching the fix.
> > >
> > > I installed the attached patch to Gnulib in preparation for the upcoming 
> > > glibc fix. The patch causes fchmodat with AT_SYMLINK_NOFOLLOW to work on 
> > > non-symlinks, and similarly for lchmod on non-symlinks. The idea is to 
> > > avoid this sort of problem in the future, and to let Coreutils etc. work 
> > > on older platforms as if glibc 2.32 (or whatever) is already in place.
> > 
> > The lchmod implementation based on /proc tickles an XFS bug:
> > 
> >   
> 
> Uhg, why does Linux even let the fs driver see whether the chmod is
> being performed via a filename, O_PATH fd, or magic symlink in /proc?
> It should just be an operation on the inode.

OK, I don't think it's actually clear from the test that the use of
the magic symlink is the cause. It's plausible that XFS just always
returns failure on success for this operation, and I don't have XFS to
test with.

Note that in any case, musl's lchmod/fchmodat is not affected since it
always refuses to change symlink modes; I did this because I was
worried that chmod on the magic symlink in /proc might pass through
not just to the symlink it refers to, but to the symlink target if one
exists. With current kernel versions it seems that does not happen; is
it safe to assume it doesn't?

Further, I've found some inconsistent behavior with ext4: chmod on the
magic symlink fails with EOPNOTSUPP as in Florian's test, but fchmod
on the O_PATH fd succeeds and changes the symlink mode. This is with
5.4. Cany anyone else confirm this? Is it a problem?

Rich

bug#39236: [musl] coreutils cp mishandles error return from lchmod

[Rich Felker]

On Wed, Feb 12, 2020 at 12:50:19PM +0100, Florian Weimer wrote:
> * Paul Eggert:
> 
> > On 1/22/20 2:05 PM, Rich Felker wrote:
> >> I think we're approaching a consensus that glibc should fix this too,
> >> so then it would just be gnulib matching the fix.
> >
> > I installed the attached patch to Gnulib in preparation for the upcoming 
> > glibc fix. The patch causes fchmodat with AT_SYMLINK_NOFOLLOW to work on 
> > non-symlinks, and similarly for lchmod on non-symlinks. The idea is to 
> > avoid this sort of problem in the future, and to let Coreutils etc. work 
> > on older platforms as if glibc 2.32 (or whatever) is already in place.
> 
> The lchmod implementation based on /proc tickles an XFS bug:
> 
>   

Uhg, why does Linux even let the fs driver see whether the chmod is
being performed via a filename, O_PATH fd, or magic symlink in /proc?
It should just be an operation on the inode.

Rich

bug#39236: [musl] coreutils cp mishandles error return from lchmod

[Florian Weimer]

* Paul Eggert:

> On 1/22/20 2:05 PM, Rich Felker wrote:
>> I think we're approaching a consensus that glibc should fix this too,
>> so then it would just be gnulib matching the fix.
>
> I installed the attached patch to Gnulib in preparation for the upcoming 
> glibc fix. The patch causes fchmodat with AT_SYMLINK_NOFOLLOW to work on 
> non-symlinks, and similarly for lchmod on non-symlinks. The idea is to 
> avoid this sort of problem in the future, and to let Coreutils etc. work 
> on older platforms as if glibc 2.32 (or whatever) is already in place.

The lchmod implementation based on /proc tickles an XFS bug:

  

bug#39236: [musl] coreutils cp mishandles error return from lchmod

[Paul Eggert]

On 1/22/20 2:05 PM, Rich Felker wrote:

I think we're approaching a consensus that glibc should fix this too,
so then it would just be gnulib matching the fix.


I installed the attached patch to Gnulib in preparation for the upcoming 
glibc fix. The patch causes fchmodat with AT_SYMLINK_NOFOLLOW to work on 
non-symlinks, and similarly for lchmod on non-symlinks. The idea is to 
avoid this sort of problem in the future, and to let Coreutils etc. work 
on older platforms as if glibc 2.32 (or whatever) is already in place.
>From b16a04394121e7396569a13161dba02c6752b19f Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Fri, 7 Feb 2020 16:34:12 -0800
Subject: [PATCH] fchmodat: AT_SYMLINK_NOFOLLOW fix for non-symlinks

Fix lchmod, and fchmodat with AT_SYMLINK_NOFOLLOW, so that
they act like chmod on non-symlinks.
* NEWS:
* doc/glibc-functions/lchmod.texi (lchmod):
* doc/posix-functions/fchmodat.texi (fchmodat):
Mention this.
* lib/fchmodat.c: Define __need_system_sys_stat_h before including
config.h, and undef it after including sys/stat.h the first time.
Include fcntl.h, stdio.h, unistd.h, intprops.h, and include
sys/stat.h a second time after defining orig_fchmodat.
(orig_fchmodat) [HAVE_FCHMODAT]: New function.
(fchmodat) [HAVE_FCHMODAT]: Work around the AT_SYMLINK_NOFOLLOW bug.
* lib/lchmod.c: New file.
* lib/sys_stat.in.h (fchmodat, lchmod):
Support replacing these functions.
* m4/fchmodat.m4 (gl_FUNC_FCHMODAT): If fchmodat exists,
test that AT_SYMLINK_NOFOLLOW works on non-symlinks.
* m4/lchmod.m4 (gl_FUNC_LCHMOD): Check for lstat.
Test that lchmod works on non-symlinks.
* m4/sys_stat_h.m4 (gl_SYS_STAT_H_DEFAULTS):
Default REPLACE_FCHMODAT and REPLACE_LCHMOD to 0.
* modules/fchmodat (Depends-on): Add fstatat, intprops, lchmod, unistd.
(Depends-on, configure.ac): Check REPLACE_FCHMODAT too.
* modules/lchmod (Files): Add lib/lchmod.c.
(Depends-on): Add errno, fcntl-h, fchmodat, intprops, lstat, unistd.
(configure.ac): Compile lchmod.c if needed.
(lib_SOURCES): Add lchmod.c.
* modules/sys_stat (sys/stat.h): Substitute REPLACE_FCHMODAT
and REPLACE_LCHMOD.
* tests/test-fchmodat.c: Include fcntl.h, sys/stat.h.
(main): Test fchmodat with AT_SYMLINK_NOFOLLOW on non-symlinks.
---
 ChangeLog | 35 
 NEWS  |  7 +++
 doc/glibc-functions/lchmod.texi   |  4 ++
 doc/posix-functions/fchmodat.texi | 11 ++--
 lib/fchmodat.c| 89 +--
 lib/lchmod.c  | 72 +
 lib/sys_stat.in.h | 41 +++---
 m4/fchmodat.m4| 48 -
 m4/lchmod.m4  | 52 --
 m4/sys_stat_h.m4  |  4 +-
 modules/fchmodat  | 10 ++--
 modules/lchmod| 13 -
 modules/sys_stat  |  2 +
 tests/test-fchmodat.c | 10 
 14 files changed, 348 insertions(+), 50 deletions(-)
 create mode 100644 lib/lchmod.c

diff --git a/ChangeLog b/ChangeLog
index 99e0c2e9e..71dcaba6c 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,38 @@
+2020-02-07  Paul Eggert  
+
+	fchmodat: AT_SYMLINK_NOFOLLOW fix for non-symlinks
+	Fix lchmod, and fchmodat with AT_SYMLINK_NOFOLLOW, so that
+	they act like chmod on non-symlinks.
+	* NEWS:
+	* doc/glibc-functions/lchmod.texi (lchmod):
+	* doc/posix-functions/fchmodat.texi (fchmodat):
+	Mention this.
+	* lib/fchmodat.c: Define __need_system_sys_stat_h before including
+	config.h, and undef it after including sys/stat.h the first time.
+	Include fcntl.h, stdio.h, unistd.h, intprops.h, and include
+	sys/stat.h a second time after defining orig_fchmodat.
+	(orig_fchmodat) [HAVE_FCHMODAT]: New function.
+	(fchmodat) [HAVE_FCHMODAT]: Work around the AT_SYMLINK_NOFOLLOW bug.
+	* lib/lchmod.c: New file.
+	* lib/sys_stat.in.h (fchmodat, lchmod):
+	Support replacing these functions.
+	* m4/fchmodat.m4 (gl_FUNC_FCHMODAT): If fchmodat exists,
+	test that AT_SYMLINK_NOFOLLOW works on non-symlinks.
+	* m4/lchmod.m4 (gl_FUNC_LCHMOD): Check for lstat.
+	Test that lchmod works on non-symlinks.
+	* m4/sys_stat_h.m4 (gl_SYS_STAT_H_DEFAULTS):
+	Default REPLACE_FCHMODAT and REPLACE_LCHMOD to 0.
+	* modules/fchmodat (Depends-on): Add fstatat, intprops, lchmod, unistd.
+	(Depends-on, configure.ac): Check REPLACE_FCHMODAT too.
+	* modules/lchmod (Files): Add lib/lchmod.c.
+	(Depends-on): Add errno, fcntl-h, fchmodat, intprops, lstat, unistd.
+	(configure.ac): Compile lchmod.c if needed.
+	(lib_SOURCES): Add lchmod.c.
+	* modules/sys_stat (sys/stat.h): Substitute REPLACE_FCHMODAT
+	and REPLACE_LCHMOD.
+	* tests/test-fchmodat.c: Include fcntl.h, sys/stat.h.
+	(main): Test fchmodat with AT_SYMLINK_NOFOLLOW on non-symlinks.
+
 2020-02-05  Marc Dionne(tiny change)
 
 	mountlist: Consider AFS filesystems as remote
diff --git a/NEWS b/NEWS
index dc5cc71f9..bc81dfc28 100644
--- a/NEWS
+++ b/NEWS
@@ -58,6 +58,13 @@ User visible incompatible changes
 
 Date   

bug#39236: [musl] coreutils cp mishandles error return from lchmod

[Rich Felker]

On Wed, Jan 22, 2020 at 01:55:57PM -0800, Paul Eggert wrote:
> On 1/22/20 7:08 AM, Florian Weimer wrote:
> >I think you misread what I wrote: lchmod*always*  returns ENOSYS.  Even
> >if the file is not a symbolic link.  Likewise, fchmodat with
> >AT_SYMLINK_NOFOLLOW *always* returns ENOTSUP.
> 
> That's too bad, because coreutils (and many other applications, I
> expect) assume that lchmod (and fchmodat with AT_SYMLINK_NOFOLLOW)
> to act like chmod except not follow symlinks, in order to make it
> less likely that the application will run afoul of a symlink race
> and chmod the wrong file. Isn't that how the Linux fstatat call
> behaves? And if so, why does glibc fstatat refuse to support this
> behavior?

I think you're confusing fchmodat with fstatat. The Linux fchmodat
syscall lacks a flags argument and thus doesn't suffice to implement
fchmodat. The fstatat syscall does work.

> To work around this bug, I suppose coreutils etc. should do
> something like the following:
> 
> 1. Never use lchmod since the porting nightmare is bad enough without it.
> 
> 2. On non-glibc systems (or glibc systems where the bug is fixed),
> use fchmodat with AT_SYMLINK_NOFOLLOW.
> 
> 3. On glibc systems with the bug, use openat with
> AT_SYMLINK_NOFOLLOW and O_PATH, and then fchmod the resulting file
> descriptor.
> 
> Does this sound right? Or is there some O_PATH gotcha that I haven't
> thought about?

I think fchmod historically did not work on O_PATH file descriptors,
which is why musl is using chmod on the procfs magic symlink. However,
fchmodat might work too with an empty pathname; I'm not sure.

I think these fixes are better encapsulated as a replacement for
missing/broken fchmodat, rather than putting the logic in individual
utilities or coreutils-specific library code.

Also, note that if you want to skip checking stat to make sure you
didn't open a symlink with O_PATH, that depends on confirming
Florian's claim that the kernel documents it will not follow the
symlink.

> Come to think of it, perhaps the best thing would be to change
> Gnulib's lchmod and fchmodat modules so that they do what
> applications expect, even on buggy glibc systems. (Which would be
> ironic, since Gnulib's main goal is to put wrappers around other
> libraries so that they look more like glibc.)

I think we're approaching a consensus that glibc should fix this too,
so then it would just be gnulib matching the fix.

Rich

bug#39236: [musl] coreutils cp mishandles error return from lchmod

[Paul Eggert]

On 1/22/20 7:08 AM, Florian Weimer wrote:

I think you misread what I wrote: lchmod*always*  returns ENOSYS.  Even
if the file is not a symbolic link.  Likewise, fchmodat with
AT_SYMLINK_NOFOLLOW *always* returns ENOTSUP.


That's too bad, because coreutils (and many other applications, I 
expect) assume that lchmod (and fchmodat with AT_SYMLINK_NOFOLLOW) to 
act like chmod except not follow symlinks, in order to make it less 
likely that the application will run afoul of a symlink race and chmod 
the wrong file. Isn't that how the Linux fstatat call behaves? And if 
so, why does glibc fstatat refuse to support this behavior?


To work around this bug, I suppose coreutils etc. should do something 
like the following:


1. Never use lchmod since the porting nightmare is bad enough without it.

2. On non-glibc systems (or glibc systems where the bug is fixed), use 
fchmodat with AT_SYMLINK_NOFOLLOW.


3. On glibc systems with the bug, use openat with AT_SYMLINK_NOFOLLOW 
and O_PATH, and then fchmod the resulting file descriptor.


Does this sound right? Or is there some O_PATH gotcha that I haven't 
thought about?


Come to think of it, perhaps the best thing would be to change Gnulib's 
lchmod and fchmodat modules so that they do what applications expect, 
even on buggy glibc systems. (Which would be ironic, since Gnulib's main 
goal is to put wrappers around other libraries so that they look more 
like glibc.)

bug#39236: [musl] coreutils cp mishandles error return from lchmod

[Florian Weimer]

* Rich Felker:

> On Wed, Jan 22, 2020 at 09:48:14PM +0100, Florian Weimer wrote:
>> * Rich Felker:
>> 
>> >> Hmm.  The way I read the musl code, the O_PATH descriptor already
>> >> exists.  At this point, you can just chmod the O_PATH descriptor, and
>> >> have the kernel report EOPNOTSUPP if the file system does not support
>> >> that.
>> >
>> > Oh, you mean the second one after it's already open? Maybe that's ok.
>> 
>> Yes, that's what I meant.
>> 
>> > I was concerned it might follow the link and chmod the target at that
>> > point.
>> 
>> In my tests, it works.  I think it's also documented behavior for chown
>> on these pseudo-files.
>
> Do you know where we might find that documentation?

Ugh.  I'm probably misremembering.  It may have been a rejection of
patch to implement another f*at system call with AT_EMPTY_PATH support.
(I did find your 2013 message describing the chmod and chown behavior.)

Thanks,
Florian

bug#39236: [musl] coreutils cp mishandles error return from lchmod

[Florian Weimer]

* Rich Felker:

>> Hmm.  The way I read the musl code, the O_PATH descriptor already
>> exists.  At this point, you can just chmod the O_PATH descriptor, and
>> have the kernel report EOPNOTSUPP if the file system does not support
>> that.
>
> Oh, you mean the second one after it's already open? Maybe that's ok.

Yes, that's what I meant.

> I was concerned it might follow the link and chmod the target at that
> point.

In my tests, it works.  I think it's also documented behavior for chown
on these pseudo-files.

I also verified that closing an O_PATH descriptor does not release POSIX
advisory locks for the same file.  But I'm wondering if there's still
something we are missing.

Thanks,
Florian