Closed vbandke closed 8 months ago
Volker,
I will install a German language Windows and take a look at fixing this.
Bill
That would be very welcome. :)
I have a temporary fix, no formal testing, not even checked the manual if this is correct: I added the German date/time delimiters to function tempfn: in runtest,cmd, and this seems to work: (at least, the tests are run, and reported as being successful)
for /f "delims=/. tokens=1-3" %%a in ("%date:~4%") do (
for /f "delims=:., tokens=1-4" %%d in ("%time: =0%") do (
set "@=TMP%%c%%a%%b%%d%%e%%f%%g%random%%file_ext%"
With best regards
Volker
I'll try that out here.
Thanks
Fixed by commit ba4e9e62996c384cc035cd511323f4d387bf39d2.
Note: fixes only the specific German language issue described. Other non-English languages that use yet other different field separators will still likely fail. But we'll cross that bridge when we come to it.
Part of the build process (as initiated by hercules-helper package) includes running RUNTEST.CMD . This fails, unfortunately, on a non-English (in my case: German) Windows system.
Runtest creates a temporary file with a generated file name
%calc_mttof_rexx%
. The filename created isTMP1.2024140842
(TMP1.yyyyhhmmss
) instead ofTMP1.whatever.REXX.
The reason:
RUNTEST.CMD
uses the incorrect delimiters when scanning/parsing the date/time. In a German based Windows system, the date looks like this:07.01.2024
, which is January 7, 2024. (Note that it uses a dot as separator, not a slash!).The time, OTOH, looks like this:
14:14:32,79
(which, as you'll notice, uses colons between hh, mm and ss, but a decimal comma instead of a decimal point).Because of this, the generated REXX file fails already on the PARSE statement in line 1
With best regards
Volker Bandke