Dosbox-x: Bat file issue with version 0.83.4

[rangerxusa]

Noticed two issues when upgrading from version 0.82.26 to 0.83.4 in a .bat file:

In batch file have the following:
set bs=x (x is the ascii backspace character Dec 008 Hex 0x08
set esc=y (y is the ascii escape character Dec 27 Hex 0x1b
When the bat file is ran the set commands work correctly and I use the variables %bs% and %esc% when doing ANSI screen controls with no problems.
But whenever I do a GOTO and the parser looks for the label, of the goto when it passes these two set commands I get errors:
Unexpected control character: Dec 008 and Hex 0x08.
Unexpected control character: Dec 027 and Hex 0x1b.
The bat file does run correctly but just get these annoying errors.
I never received these errors in 0.82.26 nor in standard DosBox 0.74-3.

Also another minor change noticed. I have a couple REM statements that had the pipe | character. In 0.83.4 it seems to not ignore the pipe character in a REM statement. In 0.82.26 and in DozBox 0.74-3 pipe characters are ignored in REM statements.

Thanks

[Wengier]

I will respond to the two issues (actually only one issue) you mentioned one by one:

1. The "Unexpected control character" message in the batch file was added in the patch in commit 0aad6c3 (between 0.83.2 and 0.83.3). I think it should indeed allow control characters 8 and 27 in the batch file, so I have already fixed this in my latest pull request.

2. This is not an issue at all, but an improvement. I have tested it in a real MS-DOS system, and MS-DOS will not ignore pipe characters in REM statements either. So the behavior in 0.83.4 is correct, whereas the behavior in 0.82.26 and DOSBox 0.74.3 is simply wrong. In fact, 0.82.26 and DOSBox 0.74.3 ignore everything after the piping character (no matter where it appears), which is totally incorrect.

[joncampbell123]

@Wengier Even I did not know that :laughing:

[kcgen]

Thanks @Wengier ; can you point me to the commit that fixes it?

Side note - I wrote the "Unexpected control character code" for staging that was subsequently imported into -X, so will be handy to port the change back into staging. Thanks everyone!

[Wengier]

@kcgen In the following code of the shell_batch.cpp file:

if (c>31) {
    if (((cmd_write - cmd_buffer) + 1) < (CMD_MAXLINE - 1))
    *cmd_write++ = c;
} else {
    if (c != '\n' && c != '\r')
    shell->WriteOut(MSG_Get("SHELL_ILLEGAL_CONTROL_CHARACTER"), c, c);
}

It needs to check for characters 8 and 27 (0x1b) too, so that the "Unexpected control character code" message won't show in such case.

[Wengier]

@rangerxusa By the way, DOSBox-X 0.83.4 fully supports the piping operator as in MS-DOS, although it is recommended to set the %TEMP% environment variable beforehand (as in real DOS). For example:

DIR | MORE

Neither 0.82.26 nor DOSBox 0.74-3 support this operator, as they simply ignore everything after the pipe character.

[kcgen]

Thank you @Wengier !

[rangerxusa]

Thanks very much for the quick response. I'm glad you agree that ESC and Backspace characters should be allowed in a bat file with no errors.

I have to apologize for being lazy and not testing out the pipe character in native MS-DOS. Since the pipe character has not been supported in any DosBox builds up to this point I made an assumption it was an error not knowing that DosBox-X now supports the pipe. I agree with you that pipe character in REM should mimic native MS-DOS.

BTW, glad the pipe character now works. I have missed being able to pipe command output to another command.

I assume that in the next compiled release for download at the end of the month the ESC and Backspace character fix will be available?

Thanks again.

[Wengier]

@rangerxusa Thanks for reporting the issue about the control characters in the batch file. You did not mention what platform (Windows, Linux or macOS) you are using - the next release version will indeed be available at the end of the month, but if you are using Windows, you can download the 64-bit Windows SDL2 binary with the latest code (including all code changes and fixes up to this point) from:

Link: dosbox-x-64-update.zip

Hope this helps.

[Laci60]

I use dosbox-x 0.83.4 in windows 10 2004. I run "WM" TSR dos program to handle some menus.
I realize that when a menu appears the error message "Unexpected control character: Dec 009 and Hex 0x09" also appears then after 2-3 seconds it disappears.
I think that not only 008 and 027 chars must be checked but 009 too (char 009 is TAB).

[Wengier]

@Laci60 Did you check the Windows build I posted above? Even though I did not explicitly mention 009 (TAB) in this thread because @rangerxusa did not mention it in his original bug report, it was already included in the fix too.

[sikthehedgehog]

What's real MS-DOS behavior? Because I remember being able to throw in the triangle characters with no problems (those are in the control code area as well). I think that it only treats a few characters as special (0x0A, 0x0D, 0x1A come to mind) and passes everything else as-is to the device (so echoing a backspace will erase a character, or echoing a bell will make a beep, and anything not handled by the screen device is output as-is on screen).

Mind, I could be misremembering as this was long ago, and it's possible it may be just the late MS-DOS versions that did it (I was doing that stuff with the version that came with Windows 98) but maybe worth looking into?

[Laci60]

@Wengier : Thank you for your patch and information.
"WM" menus now works perfectly, no error messages appear at all.

[Wengier]

Already fixed in version 0.83.5.