Fixed Executing long command lines in a batch generates file name errors

[nickles]

Using TCC, I create batches on the fly generating e.g. scripts to backup my files. Such a script is tod.cmd which simply calls "winrar a -hp<some_pwd> <archive> <myfiles>" to archive the specified list of files. When executing tod.cmd in TCC, I receive the following error in the WinRar error window:

u:\data\201502161639_pcben.dat: Cannot open G:\webs\gatɆwda\base\programming\nim\tools.htm
! The system cannot find the path specified.

Note the striked, uppercase E (Unicode 0x246 or UTF-8 0xC9+0x86) which is always displayed in at least one file name, and which gets inserted into the erroneous file name (the path part is "gatwda" in the example above). Also note, that there are no access problems, and that the files *do* exist. The standard code page on my system is Windows 1252, the error appears independent from storing the batch file as UTF-8 or Latin-1.

This error does not appear when executing the batch file in CMD.

Addendum: As far as I recall this error appeared with 17.0

 

[samintz]

Your subject seems to indicate you've isolated the issue down to "long command lines." However, your example is not a long command line. What is a long command line in your real case? How long is long?

 

[rconn]

There's no way I can debug this without an example.

 

[nickles]

@Scott: I have no indication (contrary to the title) that the error is related to "long" command lines (sorry for that), my command lines just happen to be very long (e.g. the last produced was about 4k characters long). Also, sometimes several Ɇs appear, sometimes only one. But please note:

1) The error does not appear with CMD.
2) The error did not appear before v16 (though I would not swear on that, I have to check that with an older installation).

 

[w_krieger]

You might want to see if you can disable unicode inside the batch, probably something like a "chcp 1252" inside a set-local.

 

[nickles]

@rconn

Here's the source (needs to be adapted though...).

 

[nickles]

@w_krieger: I tried "chcp 1252", it did not help.

 

[nickles]

Can anyone confirm the error with the uploaded batch file?

 

[Charles Dye]

I don't know what it's supposed to to, but it refers to files, directories, and environment variables which I don't have. Can you boil it down to a few lines which demonstrate the issue?

 

[nickles]

@charles: You have a point ;-)

The - newly uploaded - command file is only just the vehicle to create the errant batch file (tod.cmd) which is executed in line 37 ("call %batfile%). This batch file, if executed standalone, produces the error.
The batch contains the (no longer filtered ;-) list of files that have changed in the specified YYxxx paths - hence it wouldn't make sense to publish the generated batch file as the resulting names are local to my computer...

For you to test the file, I'd recommend to fill in the YYxxx variables, and to uncomment the call of tod.cmd and its final deletion. This should produce tod.cmd which you can inspect before calling it.

 

[Charles Dye]

Nickles: x64 Take Command?

 

[Charles Dye]

I can confirm a problem (A) in TCC v17 x64 (not x86), reading long command lines from (B) OEM batch files (not UTF-16), while (C) reading line-by-line from the batch file (LOADBTM ON prevents the issue). Looks like characters at 4096-byte intervals get clobbered.

Attached is a silly batch file intended to print the letter 'A' to the screen 4096 times.

 

[nickles]

@Charles: Yes, 64 bit TCC. I can confirm the issue is not apparent in v15.

 

[nickles]

Anything new on this?
Any official statement? Rexx?

 

[rconn]

Fixed in build 76. (Windows API bug.)

 

[nickles]

Thx Rex. Could you give us some details?

 

[nickles]

@Rex
I can confirm that the issue is gone. Which API call caused the error?