This week's book giveaways are in the Jython/Python and Object-Oriented programming forums.
We're giving away four copies each of Machine Learning for Business: Using Amazon SageMaker and Jupyter and Object Design Style Guide and have the authors on-line!
See this thread and this one for details.
Win a copy of Machine Learning for Business: Using Amazon SageMaker and JupyterE this week in the Jython/Python forum
or Object Design Style Guide in the Object-Oriented programming forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Paul Clapham
  • Jeanne Boyarsky
  • Knute Snortum
Sheriffs:
  • Liutauras Vilda
  • Tim Cooke
  • Junilu Lacar
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Joe Ess
  • salvin francis
  • fred rosenberger

Carriage return \r

 
Ranch Hand
Posts: 36
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

My carriage return displays different output on IntelliJ IDE and my Windows command prompt window.

Here is the code.
System.out.println("Happy birthday to \r you.");

My IntelliJ IDE prints:
you.

The cursor goes back to the beginning of the same line and erases all the content. I don't think this is correct.



On my Windows command prompt, it prints correctly.
you. birthday to

Cursor moves to the beginning of the same line and overrides from the beginning of the line.

Please advise.

Thanks!
 
Rancher
Posts: 133
7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, that's normal.

You can use System.lineSeparator() to get a new line (if that's what you want), it's platform-independent.
 
Marshal
Posts: 24950
61
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hopefully you weren't planning to rely on various console implementations handling carriage-returns consistently. I'm pretty sure there's no specification for how that should work -- I'm certain that Java doesn't specify it, but rather Java leaves it to the console implementation.
 
Marshal
Posts: 67464
257
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The return character (\r = U+000D) hasn't been in common use as a line end since the days when Macs were the same colour and transparency as boiled sweets. To all intents and purposes the enter/return key gives you \n on a Unix‑like box (including Linux, Chrome and OSX/Mac) and \r\n in Windows®. As AG and PC suggested, there is no such thing as “correct” behaviour for \r because it depends on the platform you are using for your display.
Try System.out.printf("Happy birthday to %n you.%n"); instead. Remember you need a %n at the end of the format String because printf() doesn't add a line separator like println(), and that there will be a space before “you” in the output because that's how you wrote the code.
 
Saloon Keeper
Posts: 21603
147
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This is the only safe form that doesn't involve extra contortions:


Note that since your original example indented one space on the second line, I've done likewise.

The original ASCII character set control characters included several end-of-line controls, each with a different function. They were, as implemented on most output hardware of the day - and specifically TeleType™ terminals:

Carriage Return: \r - 0x0d - Caused the print head/type carrier to return to the beginning of the line
Line Feed:          \n - 0x0a - Cause the paper platen to move (feed) the paper up 1 row
Form Feed:         \f - 0x0c - Cause the paper platen to move the paper up to the top of the next page

And then there were hardware tabs \t (0x09), software tabs (uncommon) and backspace \b (0x08). And MS-DOS (and CP/M) added Ctrl-Z as an end-of-text marker for disk files in fixed sectors, but that had no hardware support.

Originally these - and sometimes other - control codes were used specifically to control hardware and the software paid no attention to them. But as the need grew for formatted text records on Unix-style machines (IBM mainframes tended to use hardware end-of-line markers), certain conventions arose.

Specifically, on DEC systems and CP/M, later MS-DOS, text files would terminate lines with cr/lf. That's because the I/O services for early microcomputers were not very smart, so they used the direct hardware control characters. Often, but not always. the true end-of-line marker was taken to be the carriage return (for example in Hayes Modem "AT" commands), with the linefeed being an essential, but less meaningful appendage. And, as Campbell noted, the character mappings on PC keyboards assigned carriage return to the Return key (and to Ctrl-d). That's not as intuitive as it sounds, since mainframe ENTER keys didn't even generate a keycode. They sent the entire screen input in a single shot, rather than a character at a time like TTY devices did.

However, when Unix was created, they were more interested in smaller text files than in dumb I/O, so they used the Line Feed as the line terminator and dropped the carriage return altogether (except when overprinting lines). In such cases, "line feed" is actually "newline". Hence "\n" for the C-style escape.

The Macintosh was an aberration, since they liked to do everything their own way, and they initially dropped the linefeed and used \r as a line terminator, but they started playing around with Unix stuff, and have eventually moved to that standard.

So much for history. Here's the kicker, though. Modern terminals handle control characters in different ways, and generally there's a fairly intelligent driving mechanism for them, whether you're talking physical devices or terminal windows on a GUI screen. But despite the definition of standard control characters, different hardware manufacturers used different control codes for their more esoteric functions, such as clearing a terminal screen or fast-jump to a specific terminal position. So Unix concocted a subsystem known as termcaps (for TERMinal CAPabilities) that would map between conventional software control characters and the actual hardware control sequences. The DEC VT-100 was a popular terminal (especially since a lot of early Unix machines were re-purposed DEC equipment). But there were plenty of others, each with its own termcap database. Termcaps itself has been supplanted by something whose name escapes me, but the general principal is still the same.

So, in short, Java does not (and really can not) handle CR and LF characters in a predictable way when displaying text output. It's up to the "termcap" in effect for the output medium (or the Windows equivalent). Indeed, I can't think of anything that Java does when handling control characters with 2 exceptions: the newline character. Java adopted the conventions (probably stole some actual code) from Unix/C on newlines, so the readline() method terminates when one or more line separator characters are seen (and discarded). And the println method. Which outputs whatever the JVM's line separator property defines at the end of the text.

It should be noted, that in consonance with C conventions, println() will flush accumulated buffered text out to to the output channel. Generally, so will detection of a hard-coded end-of-line character, but don't count on it.

In brief, though, avoid explicitly playing with control characters where possible. Results can be unpredictable.

 
Campbell Ritchie
Marshal
Posts: 67464
257
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Tim Holloway wrote:. . . TeleType™ terminals: . . .

I remember the things well. I could never understand why the first key for line end was called CR=Campbell Ritchie, but I knew the second key was LF=LineFeed.
 
Tim Holloway
Saloon Keeper
Posts: 21603
147
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Campbell Ritchie wrote:

Tim Holloway wrote:. . . TeleType™ terminals: . . .

I remember the things well. I could never understand why the first key for line end was called CR=Campbell Ritchie, but I knew the second key was LF=LineFeed.



Well, on the ASR 33 teletype keyboard, there were separate keys labelled "Carriage Return" and "Line Feed" (unabbreviated). These keys. like the regular letter keys were just cylindrical buttons that you had to punch down about 10cm before they'd register. There was also a Break key, which sent no code, but physically disconnected the transmission line. For Teletype-to-Teletype communications, that made the unit on the other end chatter which tended to draw the operator's attention. Or you could also hit CTRL-g, the Bell key. And then there was the Rub Out key, which could be used to punch all the holes on a character position when creating a paper tape (error "erasure").

The TeleType long predates computers, so originally it was used for land line TTY-to-TTY and radio (RTTY) communications. But it was popular as a console for minicomputers and was relatively inexpensive when the first PCs came out.

Fun fact: Originally, the TTY baudot code was only 5 bits. The 7-bit ASCII version was a later edition.
 
Campbell Ritchie
Marshal
Posts: 67464
257
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, the buttons were cylindrical and had to be depressed had, and the machine was noisy. The two offending keys had the abbreviations CR and LF on the machine I used.
 
henry leu
Ranch Hand
Posts: 36
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

Thanks guys for all the suggestions.

However, I'm just testing it out the way the carriage return \r really works under Windows. I'm learning it.

I'm running Windows command prompt and IntelliJ IDE all on the same Windows system. Why do they show different result?

See the screenshot.

Thanks!
Capture.JPG
[Thumbnail for Capture.JPG]
 
Paul Clapham
Marshal
Posts: 24950
61
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

henry leu wrote:I'm running Windows command prompt and IntelliJ IDE all on the same Windows system. Why do they show different result?



Why not? You're probably the first person to care about that for the last 25 years. I'm not entirely joking... when Windows 95 was released, command-line programs became obsolete.
 
henry leu
Ranch Hand
Posts: 36
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Paul Clapham wrote:

henry leu wrote:I'm running Windows command prompt and IntelliJ IDE all on the same Windows system. Why do they show different result?



Why not? You're probably the first person to care about that for the last 25 years. I'm not entirely joking... when Windows 95 was released, command-line programs became obsolete.



Sorry, I mean I'm using Windows PowerShell, now Windows command prompt window.

I just realized one thing.

Different results appear on IntelliJ's RUN window and IntelliJ's TERMINAL window.

See screenshot.


Capture-1.JPG
[Thumbnail for Capture-1.JPG]
Capture-2.JPG
[Thumbnail for Capture-2.JPG]
 
Paul Clapham
Marshal
Posts: 24950
61
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So even the people at IntelliJ don't care.
 
Saloon Keeper
Posts: 11189
244
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Or maybe they did it on purpose to make people stop using '\r' and '\n' and make them use the platform independent line operations instead. :p
 
Rancher
Posts: 4450
47
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

henry leu wrote:
I'm running Windows command prompt and IntelliJ IDE all on the same Windows system. Why do they show different result?



Because they're two different applications, each treating \r subtley differently.
The same applies to the two bits of IntelliJ.
 
Campbell Ritchie
Marshal
Posts: 67464
257
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Paul Clapham wrote:. . . You're probably the first person to care about that for the last 25 years. . . .

No, about six years ago I tried running a program using \r from a dual boot machine and got different results running the same bytecode from the same memory location on the same machine depending on whether I booted into Windows® (probably Win7) or Linux (probably Fedora).
 
Tim Holloway
Saloon Keeper
Posts: 21603
147
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Dave Tolls wrote:

henry leu wrote:
I'm running Windows command prompt and IntelliJ IDE all on the same Windows system. Why do they show different result?



Because they're two different applications, each treating \r subtley differently.
The same applies to the two bits of IntelliJ.



Hey, I didn't do that long-winded explanation all for nothing. Termcaps - regardless of the platform and implementation - are not a system-wide setting. Or really, even an application-wide setting.

And don't forget that for a LONG time, Windows Notepad handled end-of-line different than Windows Wordpad!
 
Dave Tolls
Rancher
Posts: 4450
47
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Tim Holloway wrote:
Hey, I didn't do that long-winded explanation all for nothing.


Well, the OP seemed to need a cut down version.
I obviously read through it all...yes...just don't test me.
;)

Tim Holloway wrote:
And don't forget that for a LONG time, Windows Notepad handled end-of-line different than Windows Wordpad!



Ha...I had to try and explain that to a customer once.
 
To get a wish, you need a genie. To get a genie, you need a lamp. To get a lamp, you need a tiny ad:
Sauce Labs - World's Largest Continuous Testing Cloud for Websites and Mobile Apps
https://coderanch.com/t/722574/Sauce-Labs-World-Largest-Continuous
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!