[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1034344: marked as done (dash: sid dash globs no longer allow [^...] to negate a class; upcoming breaking change from bullseye)

Your message dated Mon, 29 May 2023 10:55:42 +0200
with message-id <9ff275c6-bab4-f36b-d6b3-8229e1becca2@debian.org>
and subject line Re: Bug#1028002: dash: sid dash globs no longer allow [^...] to negate a class; upcoming breaking change from bullseye
has caused the Debian Bug report #1034344,
regarding dash: sid dash globs no longer allow [^...] to negate a class; upcoming breaking change from bullseye
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
1034344: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034344
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: dash
Version: 0.5.12-2
Version: 0.5.11+git20210903+057cd650a4ed-9
Severity: wishlist

Dear Maintainer,

(I built 0.5.12-2 from the .dsc,
 the binary packages don't appear to have propagated yet.
 I also originally wrote this without knowing that glob
 classes are negated by !, not ^.
 s/correct/compatible/ and s/broken/incompatible/, i guess)

Original reproducer:
  sh -xc 'rerat_secs=7200; [ "${rerat_secs%[^0-9]*}" != "$rerat_secs" ]; echo $?'
reduced for testing:
  sh -c 'i=10; echo "${i%[^0-9]*}"'

The /correct/ output, given by 0.5.11+git20200708+dd9ef66-5 (bullseye)
(and bash, and any other shell), is, naturally "10":
we're removing, from the end, a nondigit, then anything.
There are no nondigits, so nothing is removed.

Let's observe:
  bullseye$ sh -c 'i=10; echo "${i%[^0-9]*}"'
  10
  sid$ sh -c 'i=10; echo "${i%[^0-9]*}"'
  1
  0.5.12-2$ sh -c 'i=10; echo "${i%[^0-9]*}"'
  1
  trunk$ sh -c 'i=10; echo "${i%[^0-9]*}"'
  1

Ruh-roh!!! That's /horrific/.
In my original reproducer that test is for checking the input 
is an integer, this is a common pattern.

This smells an awful lot like it'd affect all globs, right?
Yeah.
  $ ls
  1  10  2  3  4  5  6  7  8  9  bin  DEBIAN  usr
  $ echo [^0-9]*  # bash, bullseye dash
  bin DEBIAN usr
  $ sh -c 'echo [^0-9]*'  # sid dash, dash 0.5.12+ trunk
  1 10 2 3 4 5 6 7 8 9

Terrifying.

Bisecting over the upstream git, I got
  commit 8f9cca055bc661c4c690a5f5e1ca71370d129bc3 (HEAD, refs/bisect/bad)
  Author: Herbert Xu <herbert@gondor.apana.org.au>
  Date:   Wed Jan 19 16:37:54 2022 +1100
  
      expand: Always quote caret when using fnmatch
  
      This patch forces ^ to be a literal when we use fnmatch.
  
      In order to allow for the extra space to quote the caret, the
      function _rmescapes will allocate up to twice the memory if the
      flag RMESCAPE_GLOB is set.
  
      Fixes: 7638476c18f2 ("shell: Enable fnmatch/glob by default")
      Reported-by: Christoph Anton Mitterer <calestyo@scientia.org>
      Suggested-by: Harald van Dijk <harald@gigawatt.nl>
      Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
as the first bad commit with default configuration (HAVE_FNMATCH=1).

I /cannot/ find a set-up where configuring like Debian
(--disable-fnmatch --disable-lineno --disable-glob)
isn't broken.




Y'know what, I bisected the Salsa git, too, but then I consulted POSIX.
Apparently, this is fine. Apparently, XCU, 2.13.1 Patterns Matching a Single Character: 
  When unquoted and outside a bracket expression, the following three
  characters shall have special meaning in the specification of patterns:
  [
    If an open bracket introduces a bracket expression as in XBD RE
    Bracket Expression, except that the <exclamation-mark> character
    ( '!' ) shall replace the <circumflex> character ( '^' ) in its
    role in a non-matching list in the regular expression notation, it
    shall introduce a pattern bracket expression. A bracket expression
    starting with an unquoted <circumflex> character produces unspecified
    results. Otherwise, '[' shall match the character itself.


Please for the love of god add this to the NEWS.
I /guarantee/ people are using '[^0-9]' to mean "not 0-9",
and similar constructs, even if they are well-versed in the shell language.

This is a breaking change going from bullseye, and quite an insidious one.
I assume my reaction is gonna mirror others' quite well.

/Please/ add this to the NEWS.

Thanks,
наб

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: x32 (x86_64)
Foreign Architectures: amd64, i386

Kernel: Linux 6.0.0-6-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dash depends on:
ii  debianutils  5.7-0.4
ii  dpkg         1.21.15
ii  libc6        2.36-7

dash recommends no packages.

dash suggests no packages.

-- debconf information excluded

Attachment: signature.asc
Description: PGP signature


--- End Message ---
--- Begin Message --- 
Hi,

On 28-05-2023 21:53, Paul Gevers wrote:

On Thu, 13 Apr 2023 11:48:10 +0200 Paul Gevers <elbrus@debian.org> wrote:

On 12-04-2023 16:57, Santiago Ruano Rincón wrote:
> If the current behaviour
> would be part of bookworm, a NEWS entry would be great.

And a release note would be worth it too I guess.


Our (crafted with Andrej) proposal is here:
https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/181


After review by Justin B Rye, this has been pushed to the Release Notes.

Paul

Attachment: OpenPGP_signature
Description: OpenPGP digital signature


--- End Message ---
Reply to: