from a global view: my first thought was that the behavior should be:
- if output handle has a console code page (GetConsoleOutputCP()), then input file has to be converted to that code page (and it seems also that native cmd.exe supports some BOM from input file, can be done in a later patch). and likely treat input file as text (to handle ctrl-z). And input CP should come from BOM presence or not. - otherwise, a simple binary copy would do
but, things are not that simple :-(
`type foo > con:` does output the whole file (no ctrl-z handling) in binary mode to the console (still using current CP for conversion)
so CP conversion (if any) comes from current output handle CP (GetConsoleOutputCP())
text vs binary mode seems to be driven by redirection or not (best solution is likely to store as global variable the output handle at cmd.exe startup and compare if current stdout handle if the initial one or not)
Did you try to reuse the COPY command helpers (at least for the binary copy)? (note also that `TYPE CON: > foo `works as `COPY CON: foo`)
Would like to have some tests for TYPE in various CP. But couldn't find a simple way to do it as default stdout in tests is not bound to a console, and if we force output to console we'll loose the output) (would require reading back console's screenbuffer)