Fix problem with *() patterns if extglob is on.

[gmoniker]

Running from cronjobs is usually fine, but on interactive shell there is a good chance that extglob is "on" and that will give *() and several other () combo's a totally different meaning in substition pattern matching.

[gmoniker]

Can someone rerun the tests? I don't think the failure has anything to do with this PR.
DUCKDNS_TOKEN not set
getssl: DNS_ADD_COMMAND failed for domain getssl.duckdns.org

[timkimber]

Can someone rerun the tests? I don't think the failure has anything to do with this PR.
DUCKDNS_TOKEN not set
getssl: DNS_ADD_COMMAND failed for domain getssl.duckdns.org

It's not related to your change, it's because I don't have admin access to this repo so cannot set the required github secret ;-(

I'm in the middle of paralleling the tests, once that's done I'll try and make it not fail

[timkimber]

Hi @gmoniker

Can you give some more details about the error you're seeing.

I've tested with extglob on and off and have seen no difference in behaviour. All the tests and my own servers have extglob=on.

[gmoniker]

At the moment I cannot reproduce it anymore on the account where I saw it. At that moment it was switching from a APIv1 requested cert to a APIv2 requested cert, so that may be a factor. I think Bash complained about an unexpected EOF happening in the first line of these:

  if [[ "$needbase64" && ${response##*()} != "{"* ]]; then
    # response is in base64 too, decode
    response=$(urlbase64_decode "$response")
  fi

So, I looked at the pattern and I thought well that should look for parentheses, but when I tried it on a commandline that didn't work, and then I discovered that with extglob off it did work as expected, and probably as was intended by the code.

[gmoniker]

Come to think of it, it may also be that I tried the updated getssl with the version 1 API, to see if I could first swap the scripts and then swap the api setting in the configuration of the domains.

[gmoniker]

By following the flows, I have concluded that this error won't show up in tests, because the cert(chain) has already been written then. So, in all productions it won't make a difference. And when v1 disappears it won't matter anyway.

With v1 the cert appears in binary DER form, and the response variable won't hold the correct data anyway, because a construction like VAR=$(cat file) will filter all nulls (and in newer BASH produce a warning).

[rdebath]

AFAIK bash does not start with extglob turned on; one of the startup scripts has to turn it on. It is normal to link it to the interactive option (set by bash -i) but if your .bashrc isn't correctly conditioned this can cause problems.

BTW: shopt -u extglob works on bash 2.05a.0(1)-release -- Debian woody, so it should be safe to force it off if required.

On a related note I've recently noticed that git-bash on Windows turns -i on if you start a *.sh file from the GUI; so that can cause issues too.

[gmoniker]

@rdebath, From Ubuntu 16.04 in interactive shells the extglob option is 'on' by default. Without it you get errors on readline completion, because there are autocomplete dropins that use it.