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

Parser problems after build 44

Discussion in 'Support' started by RogerB, Nov 8, 2014.

  1. RogerB

    Joined:
    Apr 18, 2014
    Messages:
    142
    Likes Received:
    3
    The re-stupidification of the parser in build 44 seems to have introduced some unexpected (and unwanted!) effects. For example, this command

    Code:
    d:\>"C:\Program Files\Just Great Software\EditPad Lite 7\EditPadLite7.exe" d:\batch\test.btm
    works as expected in v16, that is Editpad lite is started with a single tab containing test.btm. In v17 b45 the same command opens Editpad lite with a total of 6 tabs, one containing test.btm and the others, all empty, titled "Editpadlite7.exe", "Just", "Great", "Lite" and "Editpad".
     
  2. mikea

    Joined:
    Dec 7, 2009
    Messages:
    210
    Likes Received:
    2
    Spaces in files' names have always seemed like my worst enemies. I always begin commands like that with "start /pgm". Does it make any difference if you do it this way: start /pgm "C:\Program Files\etc.etc.etc."?
     
  3. RogerB

    Joined:
    Apr 18, 2014
    Messages:
    142
    Likes Received:
    3
    I'll try that later, but it worked fine in v17 before b44, it works in v16 and I don't think it should be necessary to use "start" when a full path to an executable is used like that.
     
  4. mikea

    Joined:
    Dec 7, 2009
    Messages:
    210
    Likes Received:
    2
    I've occasionally seen bizarre behavior -- a text editor attempting to create a billion new files -- when I've passed arguments to a text editor at the 4NT/TCC command line. Very rare occurrence so far, but when it happened, the windows or tabs were being created so quickly that all I could do was force-shut-down the machine by holding the power button down.

    The far more common occurrence is that the command -- containing a path+filename with spaces (quoted) simply fails. And then, using "start" without "/pgm" only opens a new TCC window. TCC attempts to execute the command in the second window -- and the command fails again.

    So either I use %@sfn[] to shorten the long name, or use start /pgm -- and the problems become non-problems. In batch scripts this sometimes takes the form:

    set someVariableName=%@sfn["application's fully qualified path"]
    :: then later:
    %someVariableName [arguments here]

    As I recall, for compatibility's sake TCC attempts to emulate cmd.exe's own "start" command -- which means, alas it also inherits "start's" oddities and bugs. Sometimes "start" under cmd.exe causes the very same problem (another window opens and the command containing spaces doesn't execute properly). Well anyway, I'll be interested to see Rex's reply about this one.
     
  5. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,883
    Likes Received:
    29
    It is misbehaving. This starts a copy of EchoArgs.exe I put in "Program Files" but passes the wrong args. It looks like it's failing to pass the quotes around argv[0].
    Code:
    v:\> "c:\Program Files\EchoArgs.exe" a b c
    c:\Program
    Files\EchoArgs.exe
    a
    b
    c
    
     
  6. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,804
    Likes Received:
    82
    Fixed in build 46.
     

Share This Page