1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Inconsistent treatment of strings with backtiks

Discussion in 'Support' started by Avi Shmidman, Apr 29, 2012.

  1. Avi Shmidman

    Joined:
    Feb 23, 2012
    Messages:
    238
    Likes Received:
    3
    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.
     
  2. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,860
    Likes Received:
    83
    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).
     

Share This Page