bug#32236: df header corrupted with LANG=zh_TW.UTF-8 on macOS
Bruno Haible wrote: You can assume that mbrtowc returns 0 if and only if the multibyte sequence is a NUL byte - but you had chosen srcend in such a way that this would not happen in the loop. Thanks for the correction. I mistakenly thought that C allows multibyte encodings in which a null wide character's multibyte representation contains an all-bits-zero byte. I installed the attached to omit the unnecessary test. From 34e261fa2768533f34cf35158489ea6a22115c17 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Fri, 27 Jul 2018 12:00:02 -0700 Subject: [PATCH] df: omit redundant comparison Trivial inefficiency reported by Bruno Haible in: http://lists.gnu.org/r/bug-gnulib/2018-07/msg00109.html * src/df.c (hide_problematic_chars): Omit redundant test. --- src/df.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/df.c b/src/df.c index 9b65872..5553221 100644 --- a/src/df.c +++ b/src/df.c @@ -288,7 +288,7 @@ hide_problematic_chars (char *cell) wchar_t wc; size_t srcbytes = srcend - src; n = mbrtowc (, src, srcbytes, ); - bool ok = 0 < n && n <= srcbytes; + bool ok = n <= srcbytes; if (ok) ok = !iswcntrl (wc); -- 2.7.4
bug#32289: Fwd: Fwd: Fwd: ls -ltcr and ls -lrt report different modification dates
Forwarded Message Apologies again folks: ls -ltc and ls -lt output different information by design. Please forgive me wasting your time. L. Forwarded Message Apologies - here is the OS information: $ cat /proc/version Linux version 3.10.0-862.3.3.el7.x86_64 (buil...@kbuilder.dev.centos.org) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-28) (GCC) ) #1 SMP Fri Jun 15 04:15:27 UTC 2018 Many thanks LTC Forwarded Message Dear GNU folks I believe I have found a bug in ls in the GNU coreutils v. 8.22. My colleague and I found that 'ls' reported a different date for a gzipped log file when run with different options in a directory containing a large amount of data (1000MB). In the full listing we saw that date next to a different file in the other listing. `ls -ltcr` seems to be the one showing the correct date here. I like to use `ls -ltc` because it's my initials. My colleague was running `ls -lrt`. $ ls -ltcr ludo* -rw-rw-rw- 1 pax pax 237817 Jul 20 06:53 ludovic.tolhurst-cleaver_sabstt.com-log-20180720.gz $ ls -lrt ludo* -rw-rw-rw- 1 pax pax 237817 Jul 18 12:30 ludovic.tolhurst-cleaver_sabstt.com-log-20180720.gz I'm afraid I do not have the capability to test this on any later version of the coreutils. Thanks & regards Ludo Tolhurst-Cleaver Perl Developer SABS TT
bug#32291: Fwd: ls -ltcr and ls -lrt report different modification dates
Apologies - here is the OS information: $ cat /proc/version Linux version 3.10.0-862.3.3.el7.x86_64 (buil...@kbuilder.dev.centos.org) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-28) (GCC) ) #1 SMP Fri Jun 15 04:15:27 UTC 2018 Many thanks LTC Forwarded Message Dear GNU folks I believe I have found a bug in ls in the GNU coreutils v. 8.22. My colleague and I found that 'ls' reported a different date for a gzipped log file when run with different options in a directory containing a large amount of data (1000MB). In the full listing we saw that date next to a different file in the other listing. `ls -ltcr` seems to be the one showing the correct date here. I like to use `ls -ltc` because it's my initials. My colleague was running `ls -lrt`. $ ls -ltcr ludo* -rw-rw-rw- 1 pax pax 237817 Jul 20 06:53 ludovic.tolhurst-cleaver_sabstt.com-log-20180720.gz $ ls -lrt ludo* -rw-rw-rw- 1 pax pax 237817 Jul 18 12:30 ludovic.tolhurst-cleaver_sabstt.com-log-20180720.gz I'm afraid I do not have the capability to test this on any later version of the coreutils. Thanks & regards Ludo Tolhurst-Cleaver Perl Developer SABS TT
bug#32292: Fwd: Fwd: ls -ltcr and ls -lrt report different modification dates
Apologies again folks: ls -ltc and ls -lt output different information by design. Please forgive me wasting your time. L. Forwarded Message Apologies - here is the OS information: $ cat /proc/version Linux version 3.10.0-862.3.3.el7.x86_64 (buil...@kbuilder.dev.centos.org) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-28) (GCC) ) #1 SMP Fri Jun 15 04:15:27 UTC 2018 Many thanks LTC Forwarded Message Dear GNU folks I believe I have found a bug in ls in the GNU coreutils v. 8.22. My colleague and I found that 'ls' reported a different date for a gzipped log file when run with different options in a directory containing a large amount of data (1000MB). In the full listing we saw that date next to a different file in the other listing. `ls -ltcr` seems to be the one showing the correct date here. I like to use `ls -ltc` because it's my initials. My colleague was running `ls -lrt`. $ ls -ltcr ludo* -rw-rw-rw- 1 pax pax 237817 Jul 20 06:53 ludovic.tolhurst-cleaver_sabstt.com-log-20180720.gz $ ls -lrt ludo* -rw-rw-rw- 1 pax pax 237817 Jul 18 12:30 ludovic.tolhurst-cleaver_sabstt.com-log-20180720.gz I'm afraid I do not have the capability to test this on any later version of the coreutils. Thanks & regards Ludo Tolhurst-Cleaver Perl Developer SABS TT
bug#32289: ls -ltcr and ls -lrt report different modification dates
tag 32289 notabug close 32289 thanks On 07/27/2018 11:41 AM, Ludovic Tolhurst-Cleaver wrote: > Dear GNU folks > > I believe I have found a bug in ls in the GNU coreutils v. 8.22. > > My colleague and I found that 'ls' reported a different date for a gzipped > log file when run with different options in a directory containing a large > amount of data (1000MB). > > In the full listing we saw that date next to a different file in the other > listing. > > `ls -ltcr` seems to be the one showing the correct date here. I like to use > `ls -ltc` because it's my initials. My colleague was running `ls -lrt`. > > > $ ls -ltcr ludo* > > -rw-rw-rw- 1 pax pax 237817 Jul 20 06:53 > ludovic.tolhurst-cleaver_sabstt.com-log-20180720.gz > > $ ls -lrt ludo* > > -rw-rw-rw- 1 pax pax 237817 Jul 18 12:30 > ludovic.tolhurst-cleaver_sabstt.com-log-20180720.gz > > > I'm afraid I do not have the capability to test this on any later version of > the coreutils. > > Thanks & regards > > Ludo Tolhurst-Cleaver > Perl Developer > SABS TT 'ls' prints the modification (mtime) per default, while -c asks to display the ctime, i.e., the time of the last status change: $ ls --help | grep -A3 -F -- ' -c ' -c with -lt: sort by, and show, ctime (time of last modification of file status information); with -l: show ctime and sort by name; otherwise: sort by ctime, newest first $ touch file $ touch -m -d yesterday file $ stat file File: file Size: 0 Blocks: 0 IO Block: 4096 regular empty file Device: 820h/2080dInode: 540222 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 717/voelkerb) Gid: ( 1000/voelkerb) Access: 2018-07-27 16:11:13.073491312 +0200 Modify: 2018-07-26 16:11:32.953193672 +0200 Change: 2018-07-27 16:11:32.945894976 +0200 Birth: - $ ls -log file -rw-r--r-- 1 0 Jul 26 16:11 file $ ls -logc file -rw-r--r-- 1 0 Jul 27 16:11 file So choosing the options according to one's initials doesn't seem to be a good choice, or at least display other data than you might expect. ;-) As this is not a bug in 'ls', I'm marking it as such in our bug tracker. Of course, you can still continue the discussion by simply replying. Have a nice day, Berny
bug#32289: ls -ltcr and ls -lrt report different modification dates
Dear GNU folks I believe I have found a bug in ls in the GNU coreutils v. 8.22. My colleague and I found that 'ls' reported a different date for a gzipped log file when run with different options in a directory containing a large amount of data (1000MB). In the full listing we saw that date next to a different file in the other listing. `ls -ltcr` seems to be the one showing the correct date here. I like to use `ls -ltc` because it's my initials. My colleague was running `ls -lrt`. $ ls -ltcr ludo* -rw-rw-rw- 1 pax pax 237817 Jul 20 06:53 ludovic.tolhurst-cleaver_sabstt.com-log-20180720.gz $ ls -lrt ludo* -rw-rw-rw- 1 pax pax 237817 Jul 18 12:30 ludovic.tolhurst-cleaver_sabstt.com-log-20180720.gz I'm afraid I do not have the capability to test this on any later version of the coreutils. Thanks & regards Ludo Tolhurst-Cleaver Perl Developer SABS TT
bug#32288: date(1) Produces ISO 8601 it Won't Take Back.
Hi, coreutils 8.29-1 on Arch Linux. $ date -uIs -d @-62135596801 -12-31T23:59:59+00:00 $ date -uIs -d @-12-31T23:59:59+00:00 date: invalid date ‘@-12-31T23:59:59+00:00’ $ If date thinks it's valid ISO 8601 when it outputs it, I'd expect it to be considered valid input to take back. Cheers, Ralph.
bug#32236: df header corrupted with LANG=zh_TW.UTF-8 on macOS
Paul Eggert wrote:
> my earlier patch
> neglected the possibility that mbrtowc can return 0
I wouldn't see this as a bug: You can assume that mbrtowc returns
0 if and only if the multibyte sequence is a NUL byte - but you had
chosen srcend in such a way that this would not happen in the loop.
> and it incorrectly assumed
> wide control characters always have a single-byte representation.
Oops, you're right. My mistake as well.
The new patch looks good.
This will catch (and replace with '?') U+2028 and U+2029 on glibc systems.
On macOS, it will not do this, because iswcntrl(0x2028) and iswcntrl(0x2029)
is 0 on this system; this is consistent with the fact that the 'Terminal'
program displays these characters as simple spaces. So, no need to override
iswcntrl on macOS.
Bruno
2018-07-27 Bruno Haible
iswcntrl: Mention minor problem on macOS.
* doc/posix-functions/iswcntrl.texi: Mention oddity on macOS.
diff --git a/doc/posix-functions/iswcntrl.texi
b/doc/posix-functions/iswcntrl.texi
index 99eaa0e..44dd034 100644
--- a/doc/posix-functions/iswcntrl.texi
+++ b/doc/posix-functions/iswcntrl.texi
@@ -25,4 +25,8 @@ Portability problems not fixed by Gnulib:
@item
On AIX and Windows platforms, @code{wchar_t} is a 16-bit type and therefore
cannot
accommodate all Unicode characters.
+@item
+This function returns 0 for U+2028 (LINE SEPARATOR) and
+U+2029 (PARAGRAPH SEPARATOR) on some platforms:
+Mac OS X 10.13.
@end itemize
