If you can look at a text file with a hex editor you'll see that CR and LF are actually 1-byte characters, x'0A' and x'0D' I think, tho I forget which is which. It's been that long since I had to know! The last time I cared at all I was parsing a file one character at a time and threw away any carriage returns and I just used the Java \r to find them.
There are a bunch of other special characters in the ASCII standard, eg "formfeed" and "bell" for printers. Tab \t is the only other one I've bothered with in Java.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
In old technology, a carriage return on a printer moved the print position to the begining of the current line but stayed on the same line. A newline moved the print position to a new line but did not change the column position. Some printers can print left-right and right-left. So you print a line left-right, go to a new line and print right-left.
and the CR was used for bold or underlining (assuming the printer only worked L-R) the printers could ONLY print one character at a time. so you would print the line sans-underscores, use a carriage return, then move the printer head to the correct spot, and print the underline character. For bold, you'd print the same word again
There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors
The naming seems to have arisen from typewriters before printers. If you have ever used one of those (ancient) devices, you would know that once you type all the way to the right end of the paper, you need to do two things 1. Push the paper up one line (line feed) 2. Pull the carriage all the way to the left so that you are now positioned to type from the left edge (carriage return)
The behaviour is similar for printers (or even typing into text files). I guess the analogy would be that in a text editior, when you press Enter, should the cursor come to the line below the current line in the same column (which would mean you have to hit the "Home" key too), or should it come to the first column in the line below the current line.
Okay, so that didnt make much sense, but it sounds like a good analogy to me if someone can put it into better words
Originally posted by omkar patkar: In StringTokeinzer class, default delimiters are " newline" and "carriage return".....whats the difference between the two ?
They are different unicode character values. Nothing more can be assumed. They are just numbers. Typically, however, a newline character implies a line feed and a carriage return when sent to an character output device. Carriage return strictly means return to the left margin. It's from a device that was used in the early part of the last century. I saw one in the Smithsonian.
I suggest that this is an appropriate place to be a little pedantic, and to make sure we are clearly separating (excuse the pun) line terminators and token delimiters. The initial question was a little misleading, for those not familiar with the StringTokenizer class, in stating that default delimiters are "newline" and "carriage return". From the API doc for StringTokenizer(String str):
The tokenizer uses the default delimiter set, which is " \t\n\r\f": the space character, the tab character, the newline character, the carriage-return character, and the form-feed character. Delimiter characters themselves will not be treated as tokens.
The newline and carriage return are just two of the default delimiters. The point I want to emphasize (for Java newbies like myself) is that in the context of StringTokenizer these are token delimiters, not line terminators.
It is probably reasonable to assume that most (but not all) Strings passed to StringTokenizer begin life being read as lines. In such cases, any newlines or carriage returns in the input stream will be read (and discarded) as line terminators, and will never get as far as StringTokenizer.
Try changing that to got \rIT, then you will see it is in fact printing got, then IT over the top of it, and you should get ITt.
This is because the \r (except on older Macs) simply takes the cursor to the start of the line, not to a new line. This behaviour varies from one operating system to another, so when I tried it (with print, not println) on Linux I got
sorry to wake a sleeping thread; when I had posted a previous thread I had been referred to an old thread; so this time I thought it was better to check the existing ones before I posted a new one. Really sorry!