Question

The following command in a batch file does not work as expected/hoped:

    echo %~nxs1

Here is a sample display of what I’m trying to get:

C:\>type test.bat
@dir /b %1
@echo %~nxs1

C:\>test "C:\Documents and Settings\All Users\ntuser.dat"
ntuser.dat
NTUSER.DAT

C:\>test "C:\Documents and Settings\All Users\ntuser.data"
ntuser.data
NTUSER~1.DA~

C:\>test "C:\Documents and Settings\All Users\ntuser.dat.baz"
ntuser.dat.baz
NTUSER~1.BAZ

C:\>test "C:\Documents and Settings\All Users\foo.bar.baz"
File Not Found
foo.bar.baz (or FOO~1.BAZ or whatever, doesn’t really matter since
             file does not exist, though latter would be nice)

Instead what I get is something like the following (depending on assigned short-filenames):

C:\>type test.bat
@dir /b %1
@echo %~nxs1

C:\>test "C:\Documents and Settings\All Users\ntuser.dat"
ntuser.dat
s\ntuser.dat

C:\>test "C:\Documents and Settings\All Users\ntuser.data"
ntuser.data
s\ntuser.data

C:\>test "C:\Documents and Settings\All Users\ntuser.dat.baz"
ntuser.dat.baz
z

C:\>test "C:\Documents and Settings\All Users\foo.bar.baz"
File Not Found
s\foo.bar.baz

Basically, I need to pass a filename to a BAT file and have the script get (eg display) it as a short-filename, but only the filename and extension, no drive or path.

The help info for FOR gives %~fsI as an example, but that has the whole path as a short-filename, not just the file. Does anyone know how to combine the S parameter from %~ without getting the whole path?

Thanks a lot.

Updates

1. I am not looking for a solution in a different language, I need the BAT command to work.

2. It seems that it works for others, so I am checking to see if it is some kind of alternate configuration issue. I’m currently testing to see if Command Processor Extensions could be the cause.

3. It won’t work at all if Extensions are disabled (obviously), so I’m going on the hypothesis that it is a bug that was fixed in a subsequent service pack (the system I tested on is XP SP1). I’m testing SP2 and SP3 today…

Answer 1

Well I just confirmed it. I tested the script with CMD.EXE from XP SP1, SP2, and SP3 as well as an SP2 VM installation. It gave the aforementioned erroneous results with the SP1 version, but worked correctly in the SP2 and SP3 versions. So it is indeed a bug that was fixed. For anyone else who runs into this, the CMD.EXE file from SP2+ can be dropped into an SP1 installation without issue (assuming that an update is not feasible).