Inconsistent treatment of strings with backtiks

  • This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.
Feb 23, 2012
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.


Staff member
May 14, 2008
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).