https://bugs.winehq.org/show_bug.cgi?id=46125
--- Comment #5 from Lantizia s.maddox@lantizia.me.uk --- (In reply to Zebediah Figura from comment #4)
Unless it runs with an unescaped < in Windows (and I don't have a 32-bit machine to test with), I don't think there's a bug here.
It does.
You changed the condition of the test by removing the quotes (which I used in my example) to swap them out for an escaped operator. Which is a luxury you don't always get when it's closed source Windows software running the commands (see my original post as to how this started)... rather than the simplified example I've made with zip.exe (which is more to demonstrate the problem).
Just tried this inside Windows XP 32-bit (which still has 16-bit support)... The same command with single quotes gives 'The system cannot find the file specified', but using double quotes and it runs just fine (by fine I mean... zip.exe runs and attempts to read zip.exe as though it's a plain text file full of names and errors on the garbage)...
cmd /c "zip -@ x.zip < zip.exe"
It also worked just fine without any quotes...
cmd /c zip -@ x.zip < zip.exe
Turning to Windows 98 now... same command with single quotes gets you 'File not found' and double quotes gets you "Bad command or file name". But it's all irrelevant as it still works just fine without any quotes at all...
command /c zip -@ x.zip < zip.exe
Of course this can't be blamed on DOSBox as Wine has literally forgone actually putting the full command in the DOSBox configuration file. When looking at this DOSBox config file, it's fine that Wine removed the quotes (because if DOSBox works anything like XP/98, it doesn't need them anyway)... but it has cut off the end (and bash can't be blamed for that, as it is quoted).