By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

Inconsistent treatment of strings with backtiks

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.
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).

Similar threads