Helmut Karlowski wrote:
Same does toswin 2.6 (wich I'm using). As I recall in older MiNT-versions (1.15), \r was output on console before \n. In my own progs I always write \r\n for stderr, or stdout if its a terminal, but this it not very elegant.
I'm very surprised about that. On a standard system, \r should never be necessary with printf.I never use it and it works fine in every case (TosWin 2.7 or plain TOS). However \r\n is required for Cconws(), because there is no abstraction layer between the program and the console.
There are 2 different things with \r and "files":- For "real" files on the disk: \n must be translated to \r\n for ASCII files if the UNIXMODE environment variable does not contain "b". With this variable, the user can select his preferred end-of-line style inside files.
- For "terminals", some low-level terminal driver must translate \n into the correct sequence for newline. This must always occur, it is unrelated to the UNIXMODE variable (which is only for real files). I remember to have seen somewhere in the MiNTLib \r systematically added before \n for the TOS console, as it must be. For MiNT (especially with TOSWin) I don't know how is is done (but it works for me).
Elsewhere, no \r must be added, especially inside pipes. I remember to have made cleanup for this in the MiNTLib 1 or 2 years ago.
So beware when patching the sources with \r, it must be made at the right place (callee or caller ?).
Especially, I remember that this binary/ascii mode is OK in the MiNTLib at the stdio level (with printf, fwrite, etc.). But the binary/ascii mode is not handled at all at the UNIX level (open, write, etc...), but it should be done (like in Cygwin). This could explain some oddities with missing \r, maybe the SSH issues...
Sorry I can't do more tests right now. -- Vincent Rivière