[Bug 46125] DOS input redirection attempts are not passed into DOSBox temporary config file

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=46125

--- Comment #5 from Lantizia <s.maddox at 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).

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.