Is carriage return required when printing to a console in Windows?

It seems that just putting the line feed is good enough, but I know that it should be a carriage return + line. Does something terrible happen if you do not return the carriage and use only the lines?

This is in ANSI C and will not be redirected to a file or anything else. Just a regular console application.

+2
source share
5 answers

The Windows console follows the same line termination convention that is assumed for files, or, equivalently, for real physical terminals. He should see that CR and LF should move correctly to the next line.

However, there is a lot of software infrastructure between ANSI C and this console. In particular, any standard C library I / O function will try to do the right thing, assuming you let it get a chance. This is why the fopen() t and b modifiers were defined for the mode parameter.

With t (by default for most threads, and in particular for stdin and stdout ), any printed \n converted to a CRLF sequence, and the opposite happens for reading. To disable this behavior, use the b modifier.

By the way, terminals traditionally connected to * nix blocks, including the DEC VT100 emulated by XTerm, also need CR and LF. However, in the * nix world, conversion from a newline to a CRLF sequence is processed in the tty device driver, so most programs do not need to know about it, and t and b modifiers are ignored. On these platforms, if you need to send and receive characters to tty without this modifications, you need to look for stty (1) or the system calls it depends on.

If your ANSI C program otherwise avoids the C library I / O (perhaps because you need access to the console character color and other attributes), then whether you need to send CR or not will depend on which Win32 API calls you use to send characters.

+2
source

If you are in a * nix \ n (Linefeed) environment, this is probably normal. If you are on Windows and are not being redirected (now), then the line is also supported, but if someone redirects at some point: - (

If you are making Windows, but problems may arise if the output is redirected to a text file, then another process tries to use the data.

The console knows what to show, but consumers may be unhappy ...

If you use C #, you can try Environment.NewLine "constant".

http://msdn.microsoft.com/en-us/library/system.environment.newline.aspx

If you are really in vanilla c, you are stuck with \ r \ n. :-)

+1
source

It depends on what you use them for. Some programs will not display newlines correctly unless you put both \r and \n .

If you try to write only \n , some programs that consume your text file (or output) may display your text as one line instead of several lines.

There are also some file formats and protocols that will be completely invalid without using both \r and \n .

0
source

I have not tried this for so long that I’m not sure that I remember what is happening ... but does the row move itself down without returning to the left column?

Depending on your compiler, standard output may be opened in text mode, in which case one translation file will be converted to \ r \ n before writing.

Edit: I just tried a quick test, and in XP the file displays normally without returning. I still don't know if any compilers insert returns for you.

0
source

In C, files (called "streams") are presented in two versions - binary or text.

The meaning of this difference remains implementation / platform dependent, but on Windows (with the usual implementations I saw) when writing to text streams, \ n 'automatically translates to "\ r \ n", and when reading from text streams, "\ r \ n "automatically translates to" \ n ".

"Console" is actually "standard output", which is a stream opened by default as a text stream. So, in practice on Windows, writing "Hello, world! \ N" should be enough - and portable.

0
source

All Articles