Parser problems after build 44

[RogerB]

The re-stupidification of the parser in build 44 seems to have introduced some unexpected (and unwanted!) effects. For example, this command

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

 

[mikea]

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."?

 

[RogerB]

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.

 

[mikea]

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.

 

[vefatica]

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

v:\> "c:\Program Files\EchoArgs.exe" a b c
c:\Program
Files\EchoArgs.exe
a
b
c

 

[rconn]

The re-stupidification of the parser in build 44 seems to have introduced some unexpected (and unwanted!) effects. For example, this command

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

Fixed in build 46.