BJ> When I get the chance, I'm going to have to look at how you are 
 BJ> currently handling file name processing in the 
 BJ> port.  There is some funky interactions of that 
 BJ> code along with handling of file extension 
 BJ> information along with how that interacts with the 
 BJ> wildcard capability of the unix type of shells....  
 BJ> Some wild card options that work with the tools 
 BJ> under OS/2 don't work  under Linux.  Part of this 
 BJ> is the issue of how the shell is interpreting wild 
 BJ> cards, where under OS/2 the shell passed the info 
 BJ> on to the program for interpretation.....  I may 
 BJ> not be quoting the wild cards properly to get past 
 BJ> the shell....
 
Here's how it works.. 
 
If Maximus/Squish get an actual wildcard from somewhere (e.g. internally
generated, config file, etc), they should be processing it with the
routines in ffind.c (FindOpen, FindNext). This in turn [current] translates
the calls as best as it can to a case-insensitive glob expression, and uses
the os-level glob() to do the wildcard. This should handle 99.99% of cases,
particularly under Linux + glibc.
 
If you're doing wildcarding from the shell (e.g. as parameters do some
tool, like mecca), the SHELL will expand the wildcard into multiple
arguments on argv, as long as it matches at least one file (otherwise, the
glob expression is passed as the argument). If you use SINGLE QUOTES around
your wildcard (or escape it with backslash), the shell will not expand the
wildcard; and rather pass the expression raw.
 
Another (horrible) technique, depending on what you're doing, looks
something like this:
 
for file in *.mec
do
  mecca $file
done
 
Wes

--- Maximus/2 3.01