2

Let's have the following code (here in python):

print("something\r any")

When running it in a console, this correctly produce:

 anything

(after printing something, the caret returns back to the beginning of the same line, and then overwrite the first four characters with any)

However, the same command in a redirection will produce:

something
 any

which is incorrect. Why is it so ? Is there something to tell the shell to rewrite the current line when redirecting ?

About the definition of CR and LF:

A line feed means moving one line forward. The code is \n. A carriage return means moving the cursor to the beginning of the line. The code is \r.

3

When you redirect output, the bytes are written to destination unprocessed. How do you imagine, for example, ANSI sequences for color manipulation may be "processed" when redirected? Same with CR. It's just written to output.

Applications may detect that they are not connected to real tty device and choose different mode, "processing" codes internally. Perhaps, ncurses applications do that, but that's a courtesy I believe.

On the other hand, when you cat or type that captured file, raw codes would be processed by the tty device.

  • Well, I think it could be perfectly acceptable that the processing is done in a redirection by just dropping color codes for example (and handling CR correctly) – Synxis Apr 8 '16 at 11:05
  • Well, how do you imagine that, when you redirect output to device providing only sequential access (write in our case)? Type writers or CD-R, DVD-R writers are example. The application do not know what would come further, it can't predict, when CR without LF would appear. So, you expect to see in every application which you may ever run, the ability to cache output? What about lines containing kilo and mega-bytes, which are perfectly suitable for xml/json/scripts? This would be the courtesy of certain applications without any guarantee...p – Maximus Apr 8 '16 at 21:44
  • The shell could independently buffer the last unterminated line for such a case, but you have a point with huge xml/json lines. Maybe there should be an option for that... – Synxis Apr 8 '16 at 22:52
-1

The carriage return is supposed to return the cursor to the left margin. This is the basic functionality. The line feed is supposed to move the cursor down one line. Some software/hardware will only do the basic functionality. However other software/hardware with treat a bare carriage return and/or bare line feed as a carriage return/line feed pair. What you are seeing is variations on this behavior.

Various O/Ss and other software use either a bare carriage return or a bare line feed as a line terminator. They will normally render the line terminator by advancing to the beginning of the next line. The behavior experience requires the console to insert a carriage return when a line feed is sent. Try running you program after disabling this behavior with the command stty -onlcr. This can be reversed with the command stty onlcr or stty sane.

The output of the print statement is unprocessed and gives the correct output on the console. If you were using a different terminal you may get the same results as when it is processed while being piped.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.