expansion in bash
 

There's this statement that I've come across in Advanced Bash Scripting (Inserting a blank line between paragraphs in a text file):
I don't know exactly how to interpret the bolded part. What is the meaning of the curly brackets in this context? Does it simply mean everything ending in a dot?

It's somewhat confusing because many of those characters have special meaning in an extended regex, however, they're all used within a square brackets (list specification) so they're treated as literals (with the exception of the '.' which still has special meaning in a list and needs to be escaped).

So, unless I'm reading it wrongly, it will match any line that ends with any of '*' '{' '}' or '.' characters.

edit: actually, I got that wrong. The \ and . are both literal too and it isn't an escape. God I hate reading regexs! ;)

@GazL, IMHO a dot in a [character set] is a literal dot. No need for escaping it; the preceding backslash does nothing and can be omitted.
BTW a literal backslash in a [character set] DOES need another backslash.

I don't know why I interpreted in such a complicated way. Now I understand that those are literal characters. I thought it was some special notation. Thank you :)

I'd already realised my mistake about the dot and corrected my post, but \ doesn't need escaping within a regex list element (other than any escaping it might need to stop the shell interpreting it), as can be seen here:
e.g.
As can be seen from the grep example, it's the shell that requires the additional escape not the regex pattern itself. Interestingly, [[ .... =~ '[\.]$' ]] doesn't work however. which I find surprising.

Oh, and don't you just love consistency:

bash:
ksh:
:banghead:

Related to this are the following lines in the script:
I'm also surprised that simple or double quotes don't work at all. I don't understand the reason why. I've also tried it in ksh, but it seems to behave the same.

It's clearly some weird parsing bug in bash as regex='[\.]' ; [[ 'wibble\' =~ $regex ]] && echo yes works

The reason is because the =~ token expects a regular expression to follow. If you quote it, the expression becomes a string which is then compared against, and fails.

Small perplexment
 

Why isn't this a syntax error for an unmatched single quote?

I like how a seemingly simple question produced so much interesting stuff! :) I'm also interested in your question, josephj. What makes it more weird is that if you place the single quote in the regex between the square brackets, you do have to escape it and it only works that way.

Within single quotes all characters are literal: the escape character loses its meaning.

Things get a little more complicated within double-quotes and different shell implementations can vary with how they interpret the escape character: it will depend on what follows it. Basically it's all a bit of a mess.

Regexes! Can't live with them. Can't live without them.
 

Regexes make me dizzy. I'm gradually getting better at them over the years, but I'm still a beginner.

I even read a whole O'Reilly book on them once and still didn't absorb much.

I can't find the actual strip at the moment, but User Friendly summed it up nicely:

I don't get the joke, but I'm never any good at those :)

The bad old days ...
 

It doesn't work so well without the cartoon (he's looking over her shoulder at her CRT terminal) - and in the bad old days, we used 300 baud modems (and 110 before that - divide by roughly 10 for characters per second) to dial into time sharing systems. If the line quality was low, you'd get garbage characters sent or received (generated by noise on the transmission lines - the encoding used analog tones) - which don't look that different from a typical regex.

The realisation that there are generations out there that have never experienced serial terminals and line noise and need this joke explaining to them suddenly makes me feel very old.