Re: Bash parameter expansion (remove largest trailing match, remove largest leading match, pattern replacement) does not work

[Bruce Lilly]

On Sat, Aug 29, 2020 at 4:53 PM Koichi Murase <myoga.murase@gmail.com> 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 <bruce.lilly@gmail.com>:
> > 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.