- Dec
- 238
- 2
A search didn't quickly turn up a topic like this...
I was using a semi-ancient version of TCC and am now using:
TCC 20.00.14 x64 Windows 10 [Version 6.3.14393]
TCC Build 14 Windows 10 Build 14393
I don't recall having had problems with %@sfn[] in the past, but I'm seeing some now. Example:
I made a "Program Files" directory on D: as well.
Now change the "D:" to "C:" in the variable:
d:\> set zorch=C:\Program Files
Now . . .
So the @SFN function doesn't seem to work at all with file or directory names on this laptop's D: drive. I noticed this when I upgraded from the semi-ancient TCC version to v.19 and noticed it again on installing v.20 today.
I don't recall that sort of thing being a problem in the past. Is it WAD? If so, what's the basis for the difference? And if so, is there some other way to return short filenames on D: without having to resort to using a cmd.exe-style "for" loop? (UGH)
I also notice that whereas Control+A toggles between SFNs and LFNs on drive C:, it doesn't work on drive D.
I was using a semi-ancient version of TCC and am now using:
TCC 20.00.14 x64 Windows 10 [Version 6.3.14393]
TCC Build 14 Windows 10 Build 14393
I don't recall having had problems with %@sfn[] in the past, but I'm seeing some now. Example:
c:\> echo %@sfn["Program Files"]
(result:) C:\PROGRA~1 (expected)
c:\> echo %@sfn[%programfiles]
(result:) C:\PROGRA~1
(result:) C:\PROGRA~1 (expected)
c:\> echo %@sfn[%programfiles]
(result:) C:\PROGRA~1
I made a "Program Files" directory on D: as well.
d:\> echo %@sfn["Program Files"]
(result:) D:\Program Files (unexpected)
c:\> set zorch=D:\Program Files
c:\> echo %@sfn[%zorch]
(result:) D:\Program Files
(result:) D:\Program Files (unexpected)
c:\> set zorch=D:\Program Files
c:\> echo %@sfn[%zorch]
(result:) D:\Program Files
Now change the "D:" to "C:" in the variable:
d:\> set zorch=C:\Program Files
Now . . .
d:\> echo %@sfn[%zorch]
(result:) C:\PROGRA~1
(result:) C:\PROGRA~1
So the @SFN function doesn't seem to work at all with file or directory names on this laptop's D: drive. I noticed this when I upgraded from the semi-ancient TCC version to v.19 and noticed it again on installing v.20 today.
I don't recall that sort of thing being a problem in the past. Is it WAD? If so, what's the basis for the difference? And if so, is there some other way to return short filenames on D: without having to resort to using a cmd.exe-style "for" loop? (UGH)
I also notice that whereas Control+A toggles between SFNs and LFNs on drive C:, it doesn't work on drive D.