Fixed V17 @name adding quote (") to result

[rps]

Here is an example of what V16 yields when using @name["name.ext"]

D:\BAT>ver

TCC  16.03.55 x64   Windows 7 [Version 6.1.7601]

D:\BAT>echo %@name["desc_BAT D.bat"]
desc_BAT D

D:\BAT>echo %@name["desc_BAT-D.bat"]
desc_BAT-D

Now an example using V17 which yields a double quote at the beginning of the file name.

D:\BAT>ver

TCC  17.00.59 x64   Windows 7 [Version 6.1.7601]

D:\BAT>echo %@name["desc_BAT-D.bat"]
"desc_BAT-D

D:\BAT>echo %@name["desc_BAT D.bat"]
"desc_BAT D

D:\BAT>echo %@name[desc_BAT D.bat]
desc_BAT D

These are just examples; I have a batch file that uses @name[%fname] where %fname may use quotes.

D:\BAT>ver

TCC  17.00.59 x64  Windows 7 [Version 6.1.7601]

D:\BAT>eset fname
fname="desc_BAT D.bat"

D:\BAT>*describe %@name[%fname].bak /d"Copy of %@name[%fname].bat that adds file....."
TCC: (Sys) The system cannot find the path specified.
 "D:\BAT\desc_BAT D.bak \dCopy"
TCC: (Sys) The system cannot find the file specified.
 "D:\BAT\of"

D:\BAT>

 

[rconn]

Fixed in build 60.

 

[Jay Sage]

I think you have introduced a new bug. The expression %@name[] returns an error instead of nothing. The functions @path and @ext still work as they did in the past and will return an empty string if there is no path or extension, respectively. Version 60 breaks a bunch of the aliases that I use all the time.

 

[rconn]

WAD -- the v17 parser has tightened up on a lot of bad syntax that was formerly ignored. In the case of "@name[]", I can't think of a case where you would *want* to pass it an empty string. That would mean that EVERYTHING in the pathname is empty (or you have an invalid name).

 

[Jay Sage]

In the case of "@name[]", I can't think of a case where you would *want* to pass it an empty string. That would mean that EVERYTHING in the pathname is empty (or you have an invalid name).

I have a function called MakeWild that takes a file path and turns it into a wildcarded version. The definition is something like this:

makewild=%@path[%1]%@name[%1]*.%@ext[%1]*

When no parameter is passed, this used to return *.*, which is what I wanted. Now it reports an error. I guess I'm now going to have to add extra conditional expressions to handle the null case.

 

[Jay Sage]

WAD -- the v17 parser has tightened up on a lot of bad syntax that was formerly ignored.

I should also add that @name[] did not produce an error until build 60. As I said, some aliases that I use all the time suddenly stopped working when I updated to build 60. So any parser "tightening" for this function was just introduced.

I think I have figured out a way to code my function to get around this problem, so it's not a critical issue. But it is often a huge nuisance when a function that might be passed a null string throws an error. If this problem pops up elsewhere, I guess I could write my own functions for parsing file paths.