Inconsistent treatment of strings with backtiks

[Avi Shmidman]

Filenames containing backtiks can be successfully manipulated at the TCC command line by enclosing the filename in quotes. For instance, I can copy a file named "a`a" with this command:

[c:\]copy "a`a" aaa.pdf
c:\a`a => c:\aaa.pdf
1 file copied

However, when passing the name of the file to a function, still enclosed in quotes, TCC returns an error:

[c:\]echo %@NAME["a`a.pdf"]
TCC: No closing quote

I believe that in the latter example the parser objects because there is an uneven number of backtiks. However, shouldn't the parser be ignoring a backtik within quotes? I find that adding an escape character before the backtik doesn't help matters, either.
The only way I can get the parser to process the latter command is by first running SETDOS /X-7. However, if I do that, I worry that I'll run into other problems with long filenames, because, according to the docs, /X-7 disables the operation of double quotes, too.

 

[rconn]

It's not what you think.

The double quotes are removing during the @NAME expansion, so now you've got this on the command line:

echo a`a

and that's what is returning the "No closing quote" error.

You can work around it by using two escapes:

echo %@NAME["a^^`a.pdf"]

Or (much better idea) don't use back quotes in your file names! Even CMD.EXE will choke on those in some commands (like FOR).