Path: csiph.com!goblin1!goblin.stu.neva.ru!usenet.stanford.edu!not-for-mail From: Bruce Lilly Newsgroups: gnu.bash.bug Subject: Re: Bash parameter expansion (remove largest trailing match, remove largest leading match, pattern replacement) does not work Date: Sat, 29 Aug 2020 20:41:54 -0400 Lines: 57 Approved: bug-bash@gnu.org Message-ID: References: NNTP-Posting-Host: lists.gnu.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: usenet.stanford.edu 1598748159 11454 209.51.188.17 (30 Aug 2020 00:42:39 GMT) X-Complaints-To: action@cs.stanford.edu Cc: bug-bash@gnu.org To: Koichi Murase Envelope-to: bug-bash@gnu.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WxLplE8g3QCOUD/ysCNudATGiXJAgEM22wqBdypErrA=; b=CtiHlIxhhXumOOQTa8PIEa90bIyfhFPc9HDOz27+NdgZQrDDm2iUzNABZ7n0J6z8MQ 1jYdT5KGtkLaip0Iynh9GH5P8jwKaU5pVzX2dW/vinwPfUk21PzUgMCKH/MjSiCgW0xw 4CGPoasRcIxHvaqCDjLOASV3mbxAQU/7tlARY3BlS+Ci/PyDelUsdq8p4UlMfKqWc4Ud z7IAD+ugqrbO/dDJsd+J39uwfp8iSRi2i++qPMaceuP3qOB5Sx+M3b3UtxcJT7lJBIvi de4gq/8FlvoB2Kj1nwlgWbOJU/Qzp9aeedj8Rsbm9sQZ7dHkUvYc6ZwCPY7QAOsov8MB JVCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WxLplE8g3QCOUD/ysCNudATGiXJAgEM22wqBdypErrA=; b=DM6TMyETXU9riUWmxop33YUETfaF4ZkmyR8VezLtMiQMj3Jk9UIpSTwl8w2Xia7wdr d7LqQsjBCiqcFmq9omPfvkXWU5iq9S1PLqcJJ2x7MqB3yX558HJfi0Ew2qIo573F15yh 28N7LNbqSzqxPINg6dU8Y8QhObgQzzy++9XlN3cLaTNbY9CgTpHxHpjdc7hujVCve66V AyopGR1Ybl7hFS9TmYxqzxaE+a8cAUE8bLc6mp4f9jVpsfeLcEYdg4qHXluHbxxfMhHB xCai/3ZYIt8Ggao2Yhes78Pbx8Z87ApEZjRj8fJSN53RpSsClEmZ9eXf69f1cyn4oE3S 4cXg== X-Gm-Message-State: AOAM533oAJBvAP8OAjN9PnNGMgY0xWLPjVRQnljiC84PICcE+kh8Bt5m PfWBEaw48l0uZkC6YX+9OLBe2pPP8LYwdowSDyU= X-Google-Smtp-Source: ABdhPJxS0lI4FZe7PoahTFDtAZDn5GTSKeksRahPBShPFmiigazAq4sFC9fLdr0opgBDLITtoiOAVAcTwEIejq7oyTQ= X-Received: by 2002:a92:1597:: with SMTP id 23mr4030395ilv.58.1598748152966; Sat, 29 Aug 2020 17:42:32 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::135; envelope-from=bruce.lilly@gmail.com; helo=mail-il1-x135.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: bug-bash@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Bug reports for the GNU Bourne Again SHell List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Mailman-Original-Message-ID: X-Mailman-Original-References: Xref: csiph.com gnu.bash.bug:16858 On Sat, Aug 29, 2020 at 4:53 PM Koichi Murase wrote: [...] > That's an interesting discussion. I don't know how you define the > "work", but basically GPL only affects the derivative > programs/software but not all the "work" including the output of the > programs or the knowledge obtained in running/developing the code. I'm using it in the sense of the GPL, as in the part of the preamble: "software and other kinds of works". It's not clearly defined; vagueness is one of the problems with the GPL. I'm assuming that for bash it basically means everything that's included in the distributed package. "Everything" is basically what GPL 3 section 5c says must be covered by the GPL. [...] > Otherwise, anyone who > read a GPL code in the past cannot write any non-GPL programs because > one cannot prove the experience of reading the GPL code doesn't affect > any code that he/she writes thereafter. I sometimes hear that someone > avoids hiring programmers who have read a GPL code in the past for > defensive purposes, but I believe it's a matter of degree. That's basically the issue, and it goes both ways (i.e. also people writing GPL'ed code based on non-GPL source (or slapping a GPL license on non-GPL code); there's a rather famous case http://undeadly.org/cgi?action=article&sid=20070913014315 ). > 2020-08-30 5:07 Bruce Lilly : > > That's surprising, as octal and hexadecimal escapes are fairly > > common. > > Yes, I know that it is confusing to those who are familiar with modern > Perl-style regular expressions. But historically, POSIX regular > expressions do not support the backslash escape sequences in bracket > expressions `[...]'. The backslash escape sequences in bracket > expressions were the extension historically. As far as I know, in > POSIX, only awk supports backslash sequences in regular expressions. Actually, it works (portably) with separator2=$'\057' > Bash 2.02 supports `shopt -s extglob', so you can assume every Bash > has the support. If you are still failing to get an expected > behavior, you can just put the line `shopt -s extglob' in the > beginning of the script. In the case of the above mentioned reduced > case, you can write like this: The magic "shopt" incantation was indeed the key: thank you. I guess this can be considered closed. It would be nice, however, if there were an environment variable that could cause bash to default to extglob. My concern is some variants of make that send recipes line-by-line to a shell, in which case each line might need to be prefixed by a test for ${BASH_VERSION} and the shopt builtin.