Bug#761157: grep -P is very slow on binary files

On 2/26/25 08:06, Vincent Lefevre wrote: Hmm... The upstream bug was closed and archived more than 3 years ago! I'm Cc'ing Paul, who closed the bug upstream. I assume the upstream bug is . BTW, the slowness (with a regexp consisting of just letters) also seems to

Bug#1080330: bug#73928: Bug#1080330: coreutils: who no longer works

On 2/19/25 09:41, Arsen Arsenović wrote: they (gdm) are a user and they have a session. Adding additional filtration can only confuse admins who compare 'who' and other tools. It is exactly that confusion that I'm trying to prevent. The man page for "who" says "who - show who is logged on", bu

Bug#1080330: bug#73928: Bug#1080330: coreutils: who no longer works

On 2025-02-19 03:26, Arsen Arsenović wrote: The case for or against there being a user called 'gdm' when one installs a Fedora system is one best presented to the Fedora hackers It's not just Fedora, it's also Ubuntu. Both systems have pseudousers named "gdm" that cannot log in (their login sh

Bug#1080330: bug#73928: Bug#1080330: coreutils: who no longer works

On 2025-02-17 00:22, Thorsten Kukuk wrote: Maybe that systemd version is too old on that systems? The systemd versions are reasonably recent. Fedora 41 has systemd 256.11 (2025-01-08) and Ubuntu 24.10 has systemd 256.5 (2024-08-31). Here are the details: On Fedora 41, "systemctl --version"

Bug#1080330: bug#73928: Bug#1080330: coreutils: who no longer works

On 2025-02-17 00:12, Bruno Haible wrote: Paul Eggert wrote: $ ./who-no-systemd # Configured normally. eggert seat02025-02-15 10:11 (login screen) eggert tty2 2025-02-15 10:11 (tty2) $ ./who-with-systemd # Configured with --enable-systemd. eggert seat0

Bug#1080330: bug#73928: Bug#1080330: coreutils: who no longer works

gets worse: $ ./who-no-systemd # Configured normally. eggert seat02025-02-15 10:11 (login screen) eggert tty2 2025-02-15 10:11 (tty2) $ ./who-with-systemd # Configured with --enable-systemd. eggert seat02025-02-15 10:11 eggert tty2 2025-02-15 10:11 Appa

Bug#1080330: bug#73928: Bug#1080330: coreutils: who no longer works

At this point I confess I don't know what changes would be needed for GNU 'who'. I see a difference of opinion as to whether 'w' works. There seem to be multiple mechanisms in play (utmp, wtmp, wtmpdb, lastlog2, logind, maybe others?) and I don't know when to use which, or even how to use them

Bug#1095421: O: rcs -- The GNU Revision Control System

On 2025-02-09 12:59, W. Kosior wrote: A quick glance at the archives of one of RCS mailing lists shows that at least Paul is still active [1]. [1] https://lists.gnu.org/archive/html/bug-rcs/ Yes, I've been committing fixes, most recently a couple of months ago. See: https://git.savannah.gnu.o

Bug#456943: bug#15444: One character can be lost if colors are enabled

On 3/25/24 08:49, Vincent Lefevre wrote: This works fine in Xterm, giving on a 80-column terminal: ... However, this triggers the bug in GNOME Terminal (and other libvte-based terminals): That's not good. Is there some escape sequence that will work on both xterm and libvte? I assume the s

Bug#1067022: man2html: Segmentation fault with tzfile(5)

On 2024-03-16 16:06, Alejandro Colomar wrote: BTW, I noticed that the upstream homepage is dead: . Is this project defunct? Yes it is. It's been defunct for many years. Attached is a patch for this particular bug. However, a brief code insp

Bug#1058752: bug#62572: Bug#1058752: bug#62572: cp --no-clobber behavior has changed

On 1/31/24 06:06, Pádraig Brady wrote: To my mind the most protective option takes precedence. That's not how POSIX works with mv -i and mv -f. The last flag wins. I assume this is so that people can have aliases or shell scripts that make -i the default, but you can override by specifying -f

Bug#1058752: bug#62572: Bug#1058752: bug#62572: cp --no-clobber behavior has changed

On 2024-01-30 03:18, Pádraig Brady wrote: So we now have the proposed change as:   - revert -n to old silent success behavior   - document -n as deprecated   - Leave --update=none as is (will be synonymous with -n)   - Provide --update=none-fail to diagnose and exit failure Thanks, that's

Bug#1058752: bug#62572: Bug#1058752: bug#62572: cp --no-clobber behavior has changed

On 1/29/24 08:11, Pádraig Brady wrote: Right, that's why I'm still leaning towards my proposal in the last mail. Well, I won't insist on doing nothing; however, the proposal needs ironing out and now's a good time to do it before installing changes.   - revert to previous exit success -n

Bug#1058752: bug#62572: Bug#1058752: bug#62572: cp --no-clobber behavior has changed

On 2024-01-28 05:22, Pádraig Brady wrote: At this stage it seems best for us go back to the original Linux behiavor (use case 3), and to silently deprecate -n in docs to document the portability issues with it. I'm not sure reverting would be best. It would introduce more confusion, and woul

Bug#1058752: bug#62572: cp --no-clobber behavior has changed

On 2023-12-16 13:46, Bernhard Voelker wrote: Whether the implementation is race-prone or not is an internal thing. I wasn't referring to the internal implementation. I was referring to cp users. With the newer Coreutils (FreeBSD) behavior, you can reliably write a script to do something if cp

Bug#1058752: bug#62572: cp --no-clobber behavior has changed

On 2023-12-15 10:49, Michael Stone wrote: There's no compelling reason to force this change Well, certainly nobody compelled us at gunpoint Stlll, Pádraig gave a reasonable summary of why the change was made, despite its incompatibility with previous behavior. (One thing I'd add is that

Bug#1041588: bug#64773: grep 3.11 -r on 100000+ files fails with "Operation not supported"

To fix just this bug (as opposed to the other Gnulib-related bugs that may be lurking) try applying the attached Gnulib patch to a grep 3.11 tarball. Closing the debbugs.gnu.org bug report, as the bug has been fixed upstream.From d4d8abb39eb02c555f062b1f83ffcfac999c582f Mon Sep 17 00:00:00 2001

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config

On 2023-03-12 08:28, Alejandro Colomar wrote: I've pushed a signed tag paul1, so you can safely check that the repo is mine (since I don't have HTTPS). Thanks, I'm not sure what exactly this means as I don't contribute to shadow-devel. As far as the remaining patches go, please use your best

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config

sed set of patches that addresses the comments you made and embodies my followups.From 324bb0e914b5470650df02bd7b64e963665d44c1 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 11 Mar 2023 00:01:02 -0800 Subject: [PATCH 1/8] Simplify change_field by using strcpy * lib/fields.c (change_field)

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config

On 2023-03-11 14:39, Alejandro Colomar wrote: I wonder if the patch is really "simplifying". It depends on how one measures simplicity. The reader will need to know strftime's API regardless; requiring the reader to also know strlcpy's API makes the reader's job harder. Also, it's less mach

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config

On 2023-03-11 13:49, Alejandro Colomar wrote: +: mempcpy (full_tty, "/dev/", sizeof"/dev/" - 1)), This is a great use case for stpcpy(3). I came up with a slightly better approach, that needs neither mempcpy nor stpcpy. I plan to send it along soon.

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config

On 2023-03-11 13:59, Alejandro Colomar wrote: If the function is allowed to dereference, then NULL is not allowed, but if the values are uninitialized, then reading any of them should also trigger UB, no? Sure, but the standard says that strftime reads only the struct tm members needed to inte

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config

On 2023-03-11 14:18, Alejandro Colomar wrote: What I'm not sure is that strftime(3) requires nonnull. glibc's strftime implementation segfaults if you pass a null pointer, so we can't pass NULL regardless of whether the strftime API in time.h uses __attribute__ ((nonnull))'.

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config

On 2023-03-11 13:59, Alejandro Colomar wrote: Unless the standard specifically allows us to do so, but I can't find anything clear. It's pretty clear if you're a time nerd like me. :-) The standard for strftime says "The appropriate characters are determined using the LC_TIME category of the

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config

On 2023-03-11 13:31, Alejandro Colomar wrote: What's this &dummy exactly for? It avoids undefined behavior. A call like strftime (buf, sizeof buf, "XXX", NULL) has undefined behavior, as near as I can make out. It's OK that the dummy is uninitialized.

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config

002). From d40e2f92f3e50d13d87393bd30b2b4b20b89a2d6 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 11 Mar 2023 00:01:02 -0800 Subject: [PATCH 1/6] Fix undefined behavior in change_field * lib/fields.c (change_field): Do not ever compute &newf[-1], as behavior is undefined. Since we

Bug#930247: bug#36148: Debian Bug#930247: grep: does not handle backreferences correctly, violating POSIX

On 2023-01-20 01:51, Santiago Ruano Rincón wrote: I'll clone the bug in Debian (and adjust severities), to make it easier to follow/differentiate both bugs. Paul, do you want me to do the same in debbugs.gnu.org? Please don't bother, since the bug is already fixed upstream.

Bug#930247: bug#36148: Debian Bug#930247: grep: does not handle backreferences correctly, violating POSIX

.From b061d24916fb9a14da37a3f2a05cb80dc65cfd38 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 5 Dec 2022 14:16:45 -0800 Subject: [PATCH] grep: bug: backref in last of multiple patterns * NEWS: Mention this. * src/dfasearch.c (GEAcompile): Trim trailing newline from the last pattern, even if it has back-references and follows a pa

Bug#1017711: bug#58956: mark_object, mark_objects(?) crash

On 2022-11-06 11:32, Eli Zaretskii wrote: My question was whether in this scenario, since the parent Emacs exits, the child Emacs can get SIGHUP, simply because its parent exited and the read end of the PTY no longer exists. Yes, my sense from the few experiments I tried, is that it's a plausib

Bug#1017711: bug#58956: mark_object, mark_objects(?) crash

On 2022-11-05 22:51, Eli Zaretskii wrote: But is it possible for a program like Emacs to get SIGHUP in such a situation, or is that highly improbable? We have standard streams of the inferior Emacs process connected via PTYs to the parent process, I believe -- does that deliver SIGHUP or SIGPIP

Bug#1017711: bug#58956: mark_object, mark_objects(?) crash

On 2022-11-04 00:00, Eli Zaretskii wrote: We need to establish what is the source of SIGHUP in these cases. "These cases" mean, AFAIU, the situations where Emacs launched an async subprocess to do native compilation (which is another Emacs process in a --batch session), and the parent Emacs sess

Bug#1019724: bug#57604: Bug#1019724: warning: stray \ before - causes autopkgtest failure

On 9/19/22 05:32, Santiago Ruano Rincón wrote: as you can read below, there are 4235 packages including the warning in their build logs. Funnily, grep is also in the list :-) Grep is on the list because Debian indirectly requires ucf to build Grep, and ucf issues the warning about stray \ bec

Bug#996560: mailman3 breaks web url

weeks before and ran fine during that time. Some update in the Debian system caused this fault. I am using Debian GNU/Linux 10.11, kernel 4.19.0-16-amd64 and libc6 2.28-10 Kind Regards Eggert

Bug#922552: [bug-diffutils] bug#36488: diffutils 3.7 make check failure ppc64le opensuse on colors test

patch is part of a release, Debian shouldn't need any patches for diffutils. For now I am closing the diffutils bug report <https://bugs.gnu.org/36488>; if I was too optimistic and the patch doesn't fix things we can always reopen it. From 9b20182d48481c7ca647ff8926feeb8e1da4f7b0

Bug#940852: tzdata should install tzdata.zi file

Package: tzdata Version: 2019c-1 The upstream tzdata by default installs a file /usr/share/zoneinfo/tzdata.zi that contains version info along with the exact source used to generate the TZif binary files. This file was introduced in tzdb 2017c but apparently Debian hasn't picked it up yet. It

Bug#867283: Crash in glibc's mktime in low-memory situations

I proposed a patch here: https://sourceware.org/bugzilla/show_bug.cgi?id=21716#c1 Please give it a try.

Bug#897653: tar 1.30 breaks pristine-tar

On 05/14/2018 07:56 AM, Antonio Terceiro wrote: I still need to study the > code a bit further to try to come up with a better suggestion. Sorry, the only suggestion I can make is that you should just use the new GNU tar. The old one was obviously busted and it generated busted tarballs.

Bug#880047: bug is still valid

I run Debian 9.1 with postgrey 1.36-3 where the bug is still valid. I had to create a file: /usr/lib/tmpfiles.d/postgrey.conf with content: d /run/postgrey 0755 root root to be able to reboot my system without problem. Cheers Eggert

Bug#883733: bug#29613: Debian Bug#883733: grep returns 0 even if there is no match

On 12/08/2017 03:11 AM, Santiago R.R. wrote: $ echo 1 | grep -E '^(11+)\1+$|^1?$' ; echo $? 1 0 Shouldn't the last grep command exit 1 too? Yes it should. This appears to be due to a longstanding bug in the glibc regular expression matcher. See: https://sourceware.or

Bug#743566: [Pkg-mc-devel] Bug#743566: mc: Failed gpm connect attempt

This bug just crashed my system by generating 2.2 GB of logs and caused a day of debugging - exactly when I needed to leave for a week.

Bug#721358: bug#28574: cross compilnng, man pages

Pádraig Brady wrote: + && : $${TZ=UTC} && export TZ\ That should be UTC0 instead of UTC, as POSIX says that TZ=UTC is not portable. Other than that it looks good to me.

Bug#873262: Info received (Bug#873262: user cannot startx session)

(Attached file was missing in last mail) I tried to reproduce the error. As a result to restart my service, I get this message: $ sudo systemctl status startkladde.service ● startkladde.service - Startkladde Loaded: loaded (/etc/systemd/system/startkladde.service; enabled; vendor preset:

Bug#873262: Info received (Bug#873262: user cannot startx session)

I tried to reproduce the error. As a result to restart my service, I get this message: $ sudo systemctl status startkladde.service ● startkladde.service - Startkladde Loaded: loaded (/etc/systemd/system/startkladde.service; enabled; vendor preset: enabled) Active: failed (Result: exit-c

Bug#498336: bug#28306: grep: option to filter non-printable characters from contents

Santiago R.R. wrote: What's your position on this? Sounds like a reasonable option, though I think I might make it another form of coloring rather than a separate option.

Bug#873262: user cannot startx session

Am Montag, 28. August 2017, 09:23:11 CEST schrieb Julien Cristau: > Control: tags -1 moreinfo > > On 08/25/2017 11:10 PM, Eggert Ehmke wrote: > > Package: xorg > > > > > > > > I upgraded a system from jessie to stretch. It is a kiosk system without >

Bug#873262: user cannot startx session

: https://bugs.launchpad.net/ubuntu/+source/xinit/+bug/1562219 Regards Eggert [1] http://wiki.x.org

Bug#532541: bug#27931: grep -o fails to count empty lines (Debain Bug #532541)

rs who want to match empty lines can use 'grep "^$"', which is what I'd expect them to do anyway (-o would be superfluous there even if it included empty matches). >From fe06a81c1fdaeda10bfdde82b43e2b18bfd1de5e Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Thu, 3

Bug#870576: Configure Emacs --without-pop or (in Emacs 26) --with-mailutils

Package: emacs25 Version: 25.1+1-4 Debian ships Emacs with the default configuration, which means it installs a separate program 'movemail' that retrieves email via the POP3 protocol. When it uses POP3, 'movemail' supports only unencrypted mail transfer, which is a significant security problem

Bug#863002: bug#27763: egrep.sh: grep missing path

Santiago Ruano Rincón wrote: As suggested by this user, it would be better if egrep/fgrep script calls grep using its absolute path. Debian bug 863002 doesn't explain why it would be better, as the original bug report is evidently a case of misunderstanding how PATH works. Although we used

Bug#852617: autoconf: AC_SYS_LARGEFILE should output to CPPFLAGS

On 01/25/2017 10:24 AM, Zack Weinberg wrote: The ChangeLog entry for the addition says "Import AC_SYS_LARGEFILE from largefile.m4 serial 12", so that sounds like there was an add-on .m4 file with the same functionality floating around prior to that - I don't know where to find copies of that file

Bug#851934: bug#23035: date: regression in timezone printing (+%Z)

8c14 into Gnulib to improve the parse_datetime2 API, and installed the attached patches into coreutils. This uncovered a bug in one of our recently-added test cases, which the attached patches also fix. From 22767d84c2d80a66d2fc886f55872616432b786d Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: F

Bug#756479: [Pkg-nagios-devel] Bug#756479: Bug#756479: nagios-nrpe-server: Ignores dont_blame_nrpe=1

Hi Alex, I would call my self an experienced programmer, I also ran into trouble with this and debugged more time than it's worth... How can I get the maintainer of this package? greetings Thorsten

Bug#842339: [Bug-tar] possible fixes for CVE-2016-6321

0efd8669b373e1f542f7205f2548456 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 29 Oct 2016 21:04:40 -0700 Subject: [PATCH] When extracting, skip ".." members * NEWS: Document this. * src/extract.c (extract_archive): Skip members whose names contain "..". --- NEWS

Bug#783122: tzdata: Wrong data for Europe/Minsk

This problem should go away (or at least be different) once Ubuntu updates to tz 2016g, which no longer uses "MSK" to abbreviate Minsk Time. 2016g uses "+03" instead, as part of the push to use numeric time zone abbreviations instead of inventing alphabetic ones.

Bug#831673: bug#24024: grep: Mixing "max-count" and "after-context" outputs too few lines

ut Control) the documentation could be clearer and I installed the attached patch. From 90a2dd8b7f93ef0a8f08741e6fcb07220f9549f6 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Wed, 7 Sep 2016 22:22:37 -0700 Subject: [PATCH] doc: define "context lines" MIME-Version: 1.0 Content-Type:

Bug#806331: [Reproducible-builds] [xz-devel] Re: xz-utils: make the selected POSIX shell stable accross build environments

On 06/15/2016 01:44 PM, Ximin Luo wrote: In such a case, it is a bug to be using $POSIX_SHELL - which only tests for conformance with POSIX and not these "other bugs that make it unusable". Gnulib can't test for all POSIX violations, only for the ones it knows about. CONFIG_SHELL lets the user

Bug#186568: bug#22793: grep -E assertion failure with back references

arn...@skeeve.com wrote: Paul Eggert wrote: With recent 'grep' you can work around the problem by configuring --with-included-regex. Not so. I did a fresh ./boostrap ./configure --with-included-regex make and it still core dumps: $ echo abc | ./s

Bug#186568: bug#22793: grep -E assertion failure with back references

With recent 'grep' you can work around the problem by configuring --with-included-regex. That has some other undesirable properties, though. This is really a glibc bug and the glibc patch could be applied to the Debian copy of glibc. Here

Bug#809007: [bug-diffutils] bug#22245: [la...@debian.org: Bug#809007: diffutils: FTBFS: FAIL: test-update-copyright.sh]

Santiago Vila wrote: I find a little bit odd that only the left brace is escaped in the git commit above. Sure, it will remove the warning about the left brace, but it looks a little bit inconsistent. It depends on which sort of consistency one wants. I mildly prefer omitting backslashes when

Bug#801825: autogen: non-free file "doc/gendocs_template" (CC-BY-ND-3.0)

Bruce Korb wrote: This file comes from gnulib. Its copyright notice came from Texinfo and I assume that was from its original contributor. Ludovic, do you know what's going on with the copyright notice of doc/gendocs_template?

Bug#792030: systemd does not reliably mount nfs shares

On Fri, 10 Jul 2015, Michael Biebl wrote: > Am 10.07.2015 um 14:05 schrieb Bodo Eggert: > > Package: systemd > > Version: 215-17+deb8u1 > > Severity: normal > > > > Dear Maintainer, > > > > when I boot my system, some of the NFS shares don't g

Bug#789475: udhcpc: valid rfc1123 hostname recognized as "bad"

On Sun, 21 Jun 2015, Geert Stappers wrote: > Control: tag -1 moreinfo > On Sun, Jun 21, 2015 at 02:14:17PM +0200, Bodo Eggert wrote: > > The valid hostname "52-54-0-12-34-56" is recognized as bad > > while it should be valid according to rfc1123 (Section 2.1). >

Bug#789475: udhcpc: valid rfc1123 hostname recognized as "bad"

Package: busybox Version: 1:1.22.0-9+deb8u1 Severity: normal Tags: d-i Dear Maintainer, The valid hostname "52-54-0-12-34-56" is recognized as bad while it should be valid according to rfc1123 (Section 2.1). - Capture of the DHCP reply: be1.lrz.bootps > 192.168.7.107.bootpc: BOOTP/DHCP,

Bug#789427: debian-installer: debian installer mkfs.ext3 hangs while formatting a new partition

Package: debian-installer Severity: normal Dear Maintainer, the mkfs.ext3 program will check for DOS disklabels before formating. Creating an extended partition and then deciding to replace it with a primary partition causes the new partition to have one. Therefore the installation stopped when

Bug#534221: (no subject)

Reported upstream as Bug 952945 https://bugzilla.mozilla.org/show_bug.cgi?id=952945 My ¢¢: If I select the tabs to stay opened, the list of opened tabs obviously should not be cleared.

Bug#772901: os-prober wrong output with grep 2.21 or later

Package: os-prober Version: 1.65 Tags: patch os-prober uses 'grep' in an unportable way, in that it assumes that the regular expression "." matches the NUL byte (all zero bits). POSIX doesn't guarantee this, and as of grep 2.21 this might not work. If os-prober assumes GNU grep the fix shoul

Bug#699325: Emacs 24.3 occasionally crashes (segfault) just after starting it

I audited the Emacs trunk source code for getenv-related races that have undefined behavior and could have the reported symptoms. I found some other races and installed a fix for them as Emacs trunk bzr 118095. I expect this patch to be harder to backport to older Emacs versions, and less urge

Bug#699325: Emacs 24.3 occasionally crashes (segfault) just after starting it

The failure scenario described in was fixed in Emacs trunk bzr 111064; see Bug#13054 . This fix is in the next Emacs release, and the fix should be easily backportable to older Emacs releases. -- To UNSUBSCRIBE, email to debian-b

Bug#758105: bug#18266: handling bytes not part of the charset, and other garbage

Paul Eggert wrote: Attached are some proposed patches which should improve the performance of grep -P when applied to binary files, among other things. I have some other ideas for boosting performance further but thought I'd publish these first. I pushed those patches, along with the att

Bug#758105: bug#18266: handling bytes not part of the charset, and other garbage

ether this will "solve" the performance problem entirely with -P and encoding errors but at least it should be heading in the right direction. From ad34b7d8556e9fc274690666ac6ded2b6576feb3 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 14 Sep 2014 11:42:08 -0700 Subject: [PROPOSED

Bug#758105: bug#18266: handling bytes not part of the charset, and other garbage

Come to think of it, grep -P misbehaves badly in multibyte locales that are not UTF-8. It should report an error and exit rather than output gibberish. I installed the attached patch to catch that. From cac91e3e233b769d60d7b5d6bc0e8afc67c0c713 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date

Bug#758105: bug#18266: handling bytes not part of the charset, and other garbage

Vincent Lefevre wrote: But both of these solutions have the drawback of working only in UTF-8 locales. Not at all; '[[:error:]]' would match a single-byte encoding error in the current locale. The tz database is interested in UTF-8 so it sets the LC_ALL environment variable to a UTF-8 local

Bug#758105: bug#18266: handling bytes not part of the charset, and other garbage

Vincent Lefevre wrote: I wonder whether anyone is interested in matching individual bytes in a file regarded as UTF-8 encoded. This seems weird. It's not weird at all. For example, suppose we invent the notation [[:error:]] to match encoding errors. Then the pattern '[[:error:]]' would matc

Bug#758105: bug#18266: handling bytes not part of the charset, and other garbage

On 09/12/2014 02:29 PM, Vincent Lefevre wrote: an option to control what happens on encoding errors would be better and sufficient. It might suffice for your use cases, but it's more complicated and less flexible than being able to match bytes within the regular expression. (Plus, someone w

Bug#758105: bug#18266: handling bytes not part of the charset, and other garbage

Vincent Lefevre wrote: Glibc regards it as ASCII: You're right. Sorry, I was confused. FreeBSD, Solaris, and AIX work the way that I thought, though. Plus, in GNU regular expressions the pattern "." works the way that I thought with LC_ALL=C; my guess (without investigating this) is that

Bug#758105: bug#18266: handling bytes not part of the charset, and other garbage

Vincent Lefevre wrote: ypig% LC_ALL=C locale charmap ANSI_X3.4-1968 That may be what the 'locale' command says, but bytes with the top bit on are considered to be valid single-byte characters. There are no encoding errors. So, in that sense it's not strict ASCII. the current behavior br

Bug#758105: bug#18266: handling bytes not part of the charset, and other garbage

Vincent Lefevre wrote: the C locale corresponds to ANSI_X3.4-1968, No it doesn't, at least not on any current platform I'm aware of. And POSIX does not require that. POSIX even allows the C locale to be multibyte, e.g., UTF-8. I would say that this should be the same for invalid byte seq

Bug#758105: bug#18266: Bug#758105: bug#18266: grep -P and invalid exits with error

a shot with the attached further patch. >From 266b8d4485053a6733e11d43a66c09d080c520fa Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Thu, 11 Sep 2014 12:05:19 -0700 Subject: [PATCH] grep: fix false matches with -P '...$' and invalid UTF-8 * tests/pcre-invalid-utf8-input: Add a

Bug#758105: bug#18266: Bug#758105: bug#18266: grep -P and invalid exits with error

114f09d51818cd703161b104e Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Thu, 11 Sep 2014 09:52:01 -0700 Subject: [PATCH] grep: fix false matches with -P '...$' and invalid UTF-8 * src/pcresearch.c (Pexecute): Use PCRE_NOTEOL when matching initial substrings of a line. --- src/pcres

Bug#758105: handling bytes not part of the charset, and other garbage

Vincent Lefevre wrote: There's no reason that '.' matches something that doesn't belong to the charset in C locale, but doesn't match in a UTF-8 locale. In the C locale on GNU/Linux, all byte values are members of the charset. That is why it's OK for '.' to accept that byte in the C locale

Bug#758105: bug#18266: grep -P and invalid exits with error

Paul Eggert wrote: perhaps there's a PCRE version dependency here? I found a PCRE-version-dependent problem that may be relevant, and installed the attached further patch to fix it. From dc7d532d16dec740d11b6817c9b558543aca0136 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Wed, 1

Bug#758105: bug#18266: grep -P and invalid exits with error

Norihiro Tanaka wrote: I see that new version has no response for following test which was used previously. printf '\x80ab\n' | env LC_ALL=en_US.utf8 src/grep -P '.?b' Thanks for reporting that. The test case works for me (Fedora 20 x86-64, GCC 4.9.1): $ printf '\x80ab\n' | env LC_AL

Bug#758105: bug#18266: grep -P and invalid exits with error

his was true even before Santiago's patch was applied). So I rewrote it and installed the attached patch instead. Please give it a try. From 29855e7bbe47b91680ae0cba5729c5becfaa3216 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 9 Sep 2014 12:41:54 -0700 Subject: [PATCH] grep:

Bug#760861: bug#18428: Bug#760861: bug#18428: coreutils binary breaks coreutils documentation

2f40bf03ecb3637625cec578371f23dcae8fc1af Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 8 Sep 2014 11:40:39 -0700 Subject: [PATCH 1/4] doc: mention which commands are optional * doc/coreutils.texi (coreutils invocation, df invocation) (stty invocation, whoami invocation, nproc invocatio

Bug#758105: grep -P and invalid exits with error

Vincent Lefevre wrote: [...] Note that this option can also be passed to pcre_exec() and pcre_dfa_exec(), to suppress the validity checking of subject strings only. If the same string is being matched many times, the option can be safely set for the second and

Bug#758105: grep -P and invalid exits with error

Thanks, but that patch seems to depend on libpcre internals, in that it "knows" that pcre_exec cannot possibly succeed without first checking its entire input buffer for invalid UTF-8 bytes. Even if that's true now, it reflects a performance bug that might be fixed in a future libpcre version.

Bug#758105: bug#18266: Bug#758105: bug#18266: grep -P and invalid exits with error

Santiago wrote: Another solution would be to don't check if binary files are valid (passing PCRE_NO_UTF8_CHECK to pcre_exec), but I don't know if that'd avoid security holes It wouldn't. (We already tried it.) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subje

Bug#758105: bug#18266: Bug#758105: bug#18266: grep -P and invalid exits with error

Vincent Lefevre wrote: On input, using null bytes may be better if one wants to be able to match real replacement characters without false positives. Maybe, though this is no place to get fancy. It's simple to tell users "an invalid byte acts like '?'". Simple is good. Anyway, this is a ma

Bug#758105: bug#18266: grep -P and invalid exits with error

Vincent Lefevre wrote: The problem with this solution is that it would change the length of the text, while replacing invalid bytes by zero bytes could be done in place (if allowed), with very little change of the code, I think. True. Though it might be more user-friendly to use '?' as the re

Bug#758105: bug#18266: grep -P and invalid exits with error

Vincent Lefevre wrote: it would be better to replace invalid UTF-8 sequences by zero bytes before passing them to libpcre. Is it allowed to do that in Pexecute()? Sorry, I don't know. I was hoping that the volunteer (whoever it is) could figure all this stuff out. grep should work correctl

Bug#758105: bug#18266: grep -P and invalid exits with error

Santiago wrote: Please, revert ca7868cc27db3d9deafaa2e0ac5a2bb0aa8ef373 That commit was necessary to avoid undefined behavior in libpcre. We can't simply undo the commit (unless you want to reintroduce security holes into grep :-). The current behavior is the best we can do, unless someone

Bug#602162: /usr/share/zoneinfo/Australia/Sydney: DST indistinguishable

This bug is fixed in the recently-released 2014f release of the tz database, and when that release propagates into Debian you should be able to close this bug report. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas

Bug#736919: bug#16586: grep: infinite loop in grep -P on some files with invalid UTF-8 sequences

Jim Meyering wrote: This bug is still present in upstream libpcre version 8.35. Ah, sorry, I thought it was Debian-specific. I've reopened grep bug 16586 , and have forwarded it to Philip Hazel, who currently has the PCRE bug assigned, according to

Bug#736919: bug#16586: grep: infinite loop in grep -P on some files with invalid UTF-8 sequences

Santiago wrote: it was a debian-pcre-specific bug. Thanks, closing the bug upstream. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#631504: (no subject)

I have to agree with Klaus Knopper. This is ridiculous. Just because you think internalizing the library would be insecure, all the users are forced to write C wrappers or compile their own ntfs-3g, which bosth will in effect be WAY LESS SECURE, because of the very reasons you are trying to avo

Bug#738546: bug#16713: [Jakub Wilk] Bug#738546: typo in gzip(1) manpage: syncronizing -> synchronizing

On 02/10/2014 07:37 AM, Bdale Garbee wrote: A user of my Debian packaging of gzip points to a typo in the man page. That's not in the upstream version, so I'm taking the liberty of closing the upstream bug report. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a

Bug#720352: bug#15147: tr: crash upon failed write(2)

I can reproduce the problem without coreutils on Ubuntu 13.04 x86-64. Compile the following program with plain "gcc foo.c" and then run "./a.out >/dev/full"; it'll dump core the same way. So it appears that this is a bug in the C library, not in coreutils. It's a fairly serious bug, I'd say. #in

Bug#452365: [Bug-tar] symlink-eating bug: the reproducer

Thanks, I just now reproduced the problem with tar 1.26 but could not reproduce it with the latest git version. this appears to be similar to this bug: http://lists.gnu.org/archive/html/bug-tar/2011-06/msg0.html which was fixed in tar upstream, here: http://lists.gnu.org/archive/html/bug-ta

Bug#598018: bug#12947: [brl...@debian.org: Bug#598018: install: temporary insecure file permissions]

Thanks, I installed this patch into the coreutils master branch, and I'm marking the upstream coreutils bug as done. >From 7ee71d9ddad1435bbea00779bcd4c62482ea3473 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 20 Nov 2012 13:15:34 -0800 Subject: [PATCH] install: fix security rac

Bug#693463: zdiff man page contains incorrect info about /tmp

Package: gzip Version: 1.5-1.1 Debian has added the following text to zdiff.1, but this addition is no longer correct, as /tmp is not used in this case on Debian in gzip 1.5. Can you please remove this from the zdiff man page? Thanks. .P When both files must be uncompressed before comparison, t

  1   2   3   >