The only non-UNIX family of patterns I am familiar with are those from MS-DOS, and command.com. Under command.com there were only 2 ``wild-card'' characters, those being ``*'' (zero or more of anything) and ``?'' (one of anything). Under DOS, with its 8.3 filename convention, * was useful after characters, but never before characters. For example, *a.exe: this pattern would pick out all .exe files as the * expanded to the entire 8 character width. The ? was useful as a generic, single character placeholder. The dot ``.'', was never actually part of the filename, it just separated the name from the extention.
UNIX has several families of regular expressions, so things are a little more complicated. First off I suppose, is this idea of a filename being composed of a name and an extention. As far as the operating system is concerned, there are no such thing as extentions. Or rather, if you want to put a special group of letters after a dot in a filename, you can. Some programs may choose to interpret this as something special, but the operating system doesn't care.
If you want a filename of a.b.c.d.e.f.g.h.i.j.k it will gladly let you make a file of that name. And it doesn't care what its contents are. Another thing this demonstrates, is that the period ``.'' doesn't mean anything special as far as filenames goes.
Some UNIX programs will append ``extentions'' to filenames after operating on a file, or expect certain ``extentions'' to be present in a filename. But this is a programmer convention, it is not something enforced by the operating system. An example of a group of programs with this behavior are the gzip family. If you compress a file with gzip, it appends ``.gz'' to the name of the file after it is finished compressing it. And if you attempt to decompress a file with gunzip (by name), it insists that the filename end in ``.gz''. But it is possible to use I/O redirection to ``pipe'' files into or out of gzip/gunzip and have filenames that do not follow these programmer enforced conventions.
Under all UNIX shells, * does expand to zero or more of any character. For example, the pattern a* does match all filenames that start with a, and *a matches all filenames that end in a. Therefore, it shouldn't surprise you that the pattern *a*e*i*o*u* matches all filenames that contain all the vowels, in order.
Like command.com, UNIX shells use the ``?'' to represent a single character of anything. Which means that ?? pattern matches all 2 character filenames.
One exception to the above is that if you want a pattern to describe one or more files which begin with a ``.'', the leading ``.'' must explicitly begin the pattern.
UNIX shells use the concept of a choice, or allow you to choose among a list of options for a pattern. The options for a choice are contained by square brackets. So, if you were looking for files that ended in a numeral, we could have *[0123456789] or *[0-9]. This last example shows that these choices can have contiguous ranges involved in them.
Sometimes it is easier to specify what you aren't looking for in a choice, than it is to specify the choice. To do this, make the first character of the list the exclamation mark ``!''. So, if you were looking for files that didn't end in a numeral, we could have *[!0-9].
In the above paragraphs, we have noticed that several characters have special meaning to the shell: *?[]|<> and there are others. What happens if we are looking for a file which contains a * as part of its name? We have to quote, or escape the special character (in this case a *). There are 3 ways of quoting things:
this=''an Egyptian'' echo ``like $this'' like an Egyptian echo 'like $this' like $this
One very important character which often needs quoting is the space. From above:
this=an Egyptian bash: Egyptian: command not found