Hallo Ted

Nice to see you back have strong opinions.

 TM> enclosed in "(" parenthesis ")". That's the way
is has always worked on 
 TM> dos-based systems. If the filename is simply wildcarded as *s, it will 
 TM> always be interpreted as *s.*, which (as you could see (enclosed) above) 
 TM> means: dos.dat matches the wildcard, but config.sys does NOT.

Under 4DOS in a LFN environment and DOS 7.1 DIR *s matches

 6.12.97  19:47             SYS
 6.12.97  19:47             WINDOWS
21.09.98  17:33           3.088  CONFIG.SYS
 3.08.98  13:06           1.063  DTPRAXIS.reg
 3.08.98  13:07             935  DTSYSTEM.reg
 3.09.98  16:19           1.782  MSDOS.$$$
 3.09.98  16:19           1.782  MSDOS.bak
21.09.98  17:28           1.862  MSDOS.SYS
 3.09.98  16:19           1.782  msdos.wtpro
 9.03.98  17:22             129  MSINPUT.INI
 1.09.98  12:35               4  sabc.dat
22.09.98   3:02           3.551  SCANDISK.LOG
15.09.98  23:38             630  TEST.BTM
18.09.98   7:39              29  TEST1.BTM

As you can see, there is a match if "S" is anywhere in filename
_or_ extension. The same command in a 4DOS SFN environment (no windows
recognition in DOS box) matches only

SYS                6.12.97  19:47
WINDOWS            6.12.97  19:47
dtpraxis.reg     1063   3.08.98  13:06
msdos.$$$        1782   3.09.98  16:19
msdos.bak        1782   3.09.98  16:19
msdos.sys        1862  21.09.98  17:28

files whose last character in the _filename_ is "S".

Under CC, in LFN _and_ SFN environments, the command DIR *s matches


SYS                    06.12.97  19:47 SYS
WINDOWS                06.12.97  19:47 WINDOWS
CONFIG   SYS         3.088  21.09.98  17:33 CONFIG.SYS
MSDOS    SYS         1.862  21.09.98  17:28 MSDOS.SYS

meaning files where the absolutely last character in in filename _or_
extension is an "S".

So your assertion 

 TM> If the filename is simply wildcarded as *s, it will always be interpreted as
 TM> *s.*, which (as you could see (enclosed) above) means: dos.dat matches the
 TM> wildcard, but config.sys does NOT.

is false. 

I put this difference in behaviour to Rex Conn. He answered me (and I hope
he doesn't mind to be quoted:

 RC> That'd be a bug in COMMAND.COM - looks like they're using 
 RC> the same wildcard matching scheme for both SFNs and LFNs.  
 RC> (Which is definitely NOT the right thing to do - extensions 
 RC> are meaningful in an SFN but not necessarily in an LFN.)

 RC> Hopefully nobody will ask me to duplicate that particular bug!










Grsse aus Ostrhauderfehn, 

*Klaus Meinhard*

--- FIPS/32 v0.99b W95/NT [M]