UNIX and Linux shells (and some other programs) accept wildcard patterns, expressions that are expanded into matching lists of filenames. The process of expanding these patterns into lists of matching filenames is called "globbing." Superficially these are similar to MS-DOS "wildcards" because MS-DOS inherited them from CP/M which
was inspired by TOPS-10 (which modeled them after UNIX?).

There is a major difference between globbing and MS-DOS wildcard handling. A glob is expanded by the shell into a list of matching filenames ''before'' the command is executed. Thus in a command:

cp *.c ../bak

The cp command (and external program under UNIX) will see a list of all the .c files followed by the name of the bak directory that's just off the parent of the current directory. The number of arguments will be the number of .c files plus one.

The MS-DOS command:

XCOPY *.C *.BAK

... has only two arguments. The program interprets the first one and calls the MS-DOS function findfirst(), then loops over a series of findnext() calls until it returns a sentinel marking that the last one has been found. The second argument is used as a template so the program replaces the * with the corresponding portion of each filename.

A UNIX command like: cp *.c *.bak is non-sensical since the cp command then sees a list of *.c and *.bak files and has no way to distinguish which filenames matched the first (shell) argument and which ones matched the second. This is a subtle distinction that new UNIX users find extremely confusing if they've become used the MS-DOS semantics.

While the MS-DOS way is convenient for one common usage pattern (copying and renaming files according to a pattern). This is more difficult under UNIX and Linux, but part of that is because UNIX filenames are not limited to the 8.3 format (eight characters with a three character extension). So the UNIX equivalent of "COPY *.TXT *.BAK" is something like:

for i in *.txt; do mv "$i" "${i%txt}bak"; done

One occasional (rare) problem with globbing in Linux occurs if, for example, there are a lot of files to deal with — the limitation on the maximum command line length (??) sometimes prevents all those files from being processed. I've heard reports of this happening on twiki.org with on the order of 7000 (rather long) file names.