bug#44248: Indentation of --help and --version

[Paul Eggert]

One way to attack the problem is (1) use only one-liners for option help, and 
(2) not worry about indentation so much (either in English or in German) as the 
excess indenting doesn't help readability enough to justify the translation 
hassle. To do that, I propose changes like the attached for comm. This will 
cause 'comm --help' output to look like the following, which is good enough and 
which will still work with help2man:


Usage: comm [OPTION]... FILE1 FILE2
Compare sorted files FILE1 and FILE2 line by line.

When FILE1 or FILE2 (not both) is -, read standard input.

With no options, produce three-column output.  Column one contains
lines unique to FILE1, column two contains lines unique to FILE2,
and column three contains lines common to both files.

  -1  suppress column 1 (lines unique to FILE1)
  -2  suppress column 2 (lines unique to FILE2)
  -3  suppress column 3 (lines that appear in both files)

  --check-order  check that the input is correctly sorted
  --nocheck-order  do not check that the input is correctly sorted
  --output-delimiter=STR  separate columns with STR
  --total  output a summary
  -z, --zero-terminated  line delimiter is NUL, not newline
  --help display this help and exit
  --version  output version information and exit

Note, comparisons honor the rules specified by 'LC_COLLATE'.

Examples:
  comm -12 file1 file2  Print only lines present in both file1 and file2.
  comm -3 file1 file2  Print lines in file1 not in file2, and vice versa.

GNU coreutils online help: 
Full documentation 
or available locally via: info '(coreutils) comm invocation'
diff --git a/src/comm.c b/src/comm.c
index 2bf8094bf..2893746cb 100644
--- a/src/comm.c
+++ b/src/comm.c
@@ -128,24 +128,23 @@ and column three contains lines common to both files.\n\
 "), stdout);
   fputs (_("\
 \n\
-  -1  suppress column 1 (lines unique to FILE1)\n\
-  -2  suppress column 2 (lines unique to FILE2)\n\
-  -3  suppress column 3 (lines that appear in both files)\n\
+  -1  suppress column 1 (lines unique to FILE1)\n\
+  -2  suppress column 2 (lines unique to FILE2)\n\
+  -3  suppress column 3 (lines that appear in both files)\n\
 "), stdout);
   fputs (_("\
 \n\
-  --check-order check that the input is correctly sorted, even\n\
-  if all input lines are pairable\n\
-  --nocheck-order   do not check that the input is correctly sorted\n\
+  --check-order  check that the input is correctly sorted\n\
+  --nocheck-order  do not check that the input is correctly sorted\n\
 "), stdout);
   fputs (_("\
   --output-delimiter=STR  separate columns with STR\n\
 "), stdout);
   fputs (_("\
-  --total   output a summary\n\
+  --total  output a summary\n\
 "), stdout);
   fputs (_("\
-  -z, --zero-terminatedline delimiter is NUL, not newline\n\
+  -z, --zero-terminated  line delimiter is NUL, not newline\n\
 "), stdout);
   fputs (HELP_OPTION_DESCRIPTION, stdout);
   fputs (VERSION_OPTION_DESCRIPTION, stdout);

bug#44248: Indentation of --help and --version

[Roland Illig]

Hi,

As the German translator of coreutils, I fixed the indentation of the
--help output today, for coreutils 8.31.90.  While doing that, I noticed
that the option "-z, --zero-terminated" is used by several programs that
have different "native" indentation widths.  Therefore their --help
output looks inconsistent.  The affected programs are: join shuf sort
uniq.  Could you perhaps give each of these programs its own message,
properly indented to match the other options?

I also noticed that the --help and --version strings are only translated
once, which is good as it saved me some boring work.  But they are
indented at a different width than the other options.  Some of the
programs add an empty line before the --help and --version lines, which
looks ok.  Several others do not add a line, which looks wrong.  This
should be consistent among all coreutils.

In src/cat.c:115, the German translation for the first example takes 2
lines instead of 1.  The second line should be aligned nicely with the
first line, but there's no way to know beforehand how long the %s from
the first line will be, since the program name may be prefixed with "g"
or "gnu-" or pretty much any other string.  What is the correct way of
solving this problem?

Roland

bug#44240: coreutils 8.30-3ubuntu2 "date" command doesn't like one specific date: 2020-09-06

[Philip Rowlands]

On Mon, 26 Oct 2020, at 15:14, Leo Wandersleb wrote:
> for some reason I get an error with one specific date but not with others:
> 
> $ for i in 08 09 10; do for j in 5 6 7; do d="2020-$i-0$j"; echo $d $( date
> -d"$d" ); done; done
> 2020-08-05 Wed 05 Aug 2020 12:00:00 AM -04
> 2020-08-06 Thu 06 Aug 2020 12:00:00 AM -04
> 2020-08-07 Fri 07 Aug 2020 12:00:00 AM -04
> 2020-09-05 Sat 05 Sep 2020 12:00:00 AM -04
> date: invalid date ‘2020-09-06’
> 2020-09-06
> 2020-09-07 Mon 07 Sep 2020 12:00:00 AM -03

The clue is the change in timezone offset from -04 to -03. The only location I 
could find which switched on 2020-09-06 was Chile, so we can reproduce the 
problem with:

$ TZ=Chile/Continental date --debug -d 2020-09-06
date: parsed date part: (Y-M-D) 2020-09-06
date: input timezone: TZ="Chile/Continental" environment value
date: warning: using midnight as starting time: 00:00:00
date: error: invalid date/time value:
date: user provided time: '(Y-M-D) 2020-09-06 00:00:00'
date:normalized time: '(Y-M-D) 2020-09-06 01:00:00'
date: --
date:  possible reasons:
date:non-existing due to daylight-saving time;
date:numeric values overflow;
date:missing timezone
date: invalid date ‘2020-09-06’

Notice that, in Chile's DST rules, the time jumps from 23:59:59 to 01:00:00:
$ zdump -v Chile/Continental | grep 2020
Chile/Continental  Sun Apr  5 02:59:59 2020 UT = Sat Apr  4 23:59:59 2020 -03 
isdst=1 gmtoff=-10800
Chile/Continental  Sun Apr  5 03:00:00 2020 UT = Sat Apr  4 23:00:00 2020 -04 
isdst=0 gmtoff=-14400
Chile/Continental  Sun Sep  6 03:59:59 2020 UT = Sat Sep  5 23:59:59 2020 -04 
isdst=0 gmtoff=-14400
Chile/Continental  Sun Sep  6 04:00:00 2020 UT = Sun Sep  6 01:00:00 2020 -03 
isdst=1 gmtoff=-10800

Therefore there is no valid time "00:00:00", and this is the "non-existing due 
to daylight-saving time" case which date --debug reports.

This is an FAQ, which often crops up twice per year:
https://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-date-command-is-not-working-right_002e


Cheers,
Phil

bug#44235: [PATCH] dd: drop old workaround for lseek() bug in Linux kernel

[Kamil Dudka]

On Monday, October 26, 2020 2:11:59 PM CET Pádraig Brady wrote:
> On 26/10/2020 10:44, Kamil Dudka wrote:
> > The workaround triggers warnings with new kernel versions in case
> > a user does not have sufficient privileges for the MTIOCGET ioctl.
> > 
> > * src/dd.c (skip_via_lseek): Drop wrapper function no longer needed.
> > (skip): Use lseek() directly.
> > (advance_input_after_read_error): Use lseek() directly.
> > 
> > Reported-by: Nir Soffer
> > Bug: https://bugzilla.redhat.com/1876840
> 
> To clarify, the kernel is warning, not dd.
> In general the kernel should be disallowing rather than warning I think.
> But yes this is old code that should no longer be needed.
> I'll apply the patch.
> 
> thanks,
> Pádraig

Perfect.  Thank you for taking a quick action on this!

Kamil

bug#44240: coreutils 8.30-3ubuntu2 "date" command doesn't like one specific date: 2020-09-06

[Leo Wandersleb]

Hi,

for some reason I get an error with one specific date but not with others:

$ for i in 08 09 10; do for j in 5 6 7; do d="2020-$i-0$j"; echo $d $( date
-d"$d" ); done; done
2020-08-05 Wed 05 Aug 2020 12:00:00 AM -04
2020-08-06 Thu 06 Aug 2020 12:00:00 AM -04
2020-08-07 Fri 07 Aug 2020 12:00:00 AM -04
2020-09-05 Sat 05 Sep 2020 12:00:00 AM -04
date: invalid date ‘2020-09-06’
2020-09-06
2020-09-07 Mon 07 Sep 2020 12:00:00 AM -03
2020-10-05 Mon 05 Oct 2020 12:00:00 AM -03
2020-10-06 Tue 06 Oct 2020 12:00:00 AM -03
2020-10-07 Wed 07 Oct 2020 12:00:00 AM -03

Regards,

Leo Wandersleb

bug#44235: [PATCH] dd: drop old workaround for lseek() bug in Linux kernel

[Jim Meyering]

On Mon, Oct 26, 2020 at 6:13 AM Pádraig Brady  wrote:
> On 26/10/2020 10:44, Kamil Dudka wrote:
> > The workaround triggers warnings with new kernel versions in case
> > a user does not have sufficient privileges for the MTIOCGET ioctl.
> >
> > * src/dd.c (skip_via_lseek): Drop wrapper function no longer needed.
> > (skip): Use lseek() directly.
> > (advance_input_after_read_error): Use lseek() directly.
> >
> > Reported-by: Nir Soffer
> > Bug: https://bugzilla.redhat.com/1876840
>
> To clarify, the kernel is warning, not dd.
> In general the kernel should be disallowing rather than warning I think.
> But yes this is old code that should no longer be needed.
> I'll apply the patch.

Thanks. Glad to see that code can be removed.
I still have that tape drive, but when I added that code (2000) may
have been the last time it was powered on.

bug#44235: [PATCH] dd: drop old workaround for lseek() bug in Linux kernel

[Pádraig Brady]

On 26/10/2020 10:44, Kamil Dudka wrote:

The workaround triggers warnings with new kernel versions in case
a user does not have sufficient privileges for the MTIOCGET ioctl.

* src/dd.c (skip_via_lseek): Drop wrapper function no longer needed.
(skip): Use lseek() directly.
(advance_input_after_read_error): Use lseek() directly.

Reported-by: Nir Soffer
Bug: https://bugzilla.redhat.com/1876840


To clarify, the kernel is warning, not dd.
In general the kernel should be disallowing rather than warning I think.
But yes this is old code that should no longer be needed.
I'll apply the patch.

thanks,
Pádraig

bug#44235: [PATCH] dd: drop old workaround for lseek() bug in Linux kernel

[Kamil Dudka]

The workaround triggers warnings with new kernel versions in case
a user does not have sufficient privileges for the MTIOCGET ioctl.

* src/dd.c (skip_via_lseek): Drop wrapper function no longer needed.
(skip): Use lseek() directly.
(advance_input_after_read_error): Use lseek() directly.

Reported-by: Nir Soffer
Bug: https://bugzilla.redhat.com/1876840
---
 src/dd.c | 59 +++-
 1 file changed, 3 insertions(+), 56 deletions(-)

diff --git a/src/dd.c b/src/dd.c
index 4b0cddc9df..be8ccc299b 100644
--- a/src/dd.c
+++ b/src/dd.c
@@ -1784,59 +1784,6 @@ advance_input_offset (uintmax_t offset)
 input_offset_overflow = true;
 }
 
-/* This is a wrapper for lseek.  It detects and warns about a kernel
-   bug that makes lseek a no-op for tape devices, even though the kernel
-   lseek return value suggests that the function succeeded.
-
-   The parameters are the same as those of the lseek function, but
-   with the addition of FILENAME, the name of the file associated with
-   descriptor FDESC.  The file name is used solely in the warning that's
-   printed when the bug is detected.  Return the same value that lseek
-   would have returned, but when the lseek bug is detected, return -1
-   to indicate that lseek failed.
-
-   The offending behavior has been confirmed with an Exabyte SCSI tape
-   drive accessed via /dev/nst0 on both Linux 2.2.17 and 2.4.16 kernels.  */
-
-#if defined __linux__ && HAVE_SYS_MTIO_H
-
-# include 
-
-# define MT_SAME_POSITION(P, Q) \
-   ((P).mt_resid == (Q).mt_resid \
-&& (P).mt_fileno == (Q).mt_fileno \
-&& (P).mt_blkno == (Q).mt_blkno)
-
-static off_t
-skip_via_lseek (char const *filename, int fdesc, off_t offset, int whence)
-{
-  struct mtget s1;
-  struct mtget s2;
-  bool got_original_tape_position = (ioctl (fdesc, MTIOCGET, ) == 0);
-  /* known bad device type */
-  /* && s.mt_type == MT_ISSCSI2 */
-
-  off_t new_position = lseek (fdesc, offset, whence);
-  if (0 <= new_position
-  && got_original_tape_position
-  && ioctl (fdesc, MTIOCGET, ) == 0
-  && MT_SAME_POSITION (s1, s2))
-{
-  if (status_level != STATUS_NONE)
-error (0, 0, _("warning: working around lseek kernel bug for file "
-   "(%s)\n  of mt_type=0x%0lx -- "
-   "see  for the list of types"),
-   filename, s2.mt_type + 0Lu);
-  errno = 0;
-  new_position = -1;
-}
-
-  return new_position;
-}
-#else
-# define skip_via_lseek(Filename, Fd, Offset, Whence) lseek (Fd, Offset, 
Whence)
-#endif
-
 /* Throw away RECORDS blocks of BLOCKSIZE bytes plus BYTES bytes on
file descriptor FDESC, which is open with read permission for FILE.
Store up to BLOCKSIZE bytes of the data at a time in IBUF or OBUF, if
@@ -1858,7 +1805,7 @@ skip (int fdesc, char const *file, uintmax_t records, 
size_t blocksize,
 
   errno = 0;
   if (records <= OFF_T_MAX / blocksize
-  && 0 <= skip_via_lseek (file, fdesc, offset, SEEK_CUR))
+  && 0 <= lseek (fdesc, offset, SEEK_CUR))
 {
   if (fdesc == STDIN_FILENO)
 {
@@ -1893,7 +1840,7 @@ skip (int fdesc, char const *file, uintmax_t records, 
size_t blocksize,
  Or it may not have been done at all (> OFF_T_MAX).
  Therefore try to seek to the end of the file,
  to avoid redundant reading.  */
-  if ((skip_via_lseek (file, fdesc, 0, SEEK_END)) >= 0)
+  if ((lseek (fdesc, 0, SEEK_END)) >= 0)
 {
   /* File is seekable, and we're at the end of it, and
  size <= OFF_T_MAX. So there's no point using read to advance.  */
@@ -1998,7 +1945,7 @@ advance_input_after_read_error (size_t nbytes)
   diff = input_offset - offset;
   if (! (0 <= diff && diff <= nbytes) && status_level != STATUS_NONE)
 error (0, 0, _("warning: invalid file offset after failed read"));
-  if (0 <= skip_via_lseek (input_file, STDIN_FILENO, diff, SEEK_CUR))
+  if (0 <= lseek (STDIN_FILENO, diff, SEEK_CUR))
 return true;
   if (errno == 0)
 error (0, 0, _("cannot work around kernel bug after all"));
-- 
2.25.4