OSDev.org

Messing around with my ext2 driver, I thought it would be cool to get my OS to sing the White Stripes. At least, print lyrics to the screen =). Just to test to make sure that I was correctly loading the text file.

Well, it correctly loads the file, and prints its content to the screen, but instead of making newlines after each line, it actually printed those little blocks with the hole in them (i.e. ASCII value 10, \n). Since I've already interpreted \n in my kprintf (which is what I'm using to print the file, for lack of a better and more suitable tool) why is it printing this little thing? Is there some sort of weird case that

if(message[index] == 10) //snip
makeanewline

wouldn't handle?

Try swapping 0x10 with 0x0A (LF = 10,0x0A/CR = 13,0x0D).

0x10 is ASCII Data Link Escape...

Or better yet:

Oops, that's actually how I had it... but typing past midnight on a school day isn't exactly the best idea in terms of accuracy. As I was saying, the function works when I call kprintf with a \n somewhere in there, but not if I kprint from the file...

hi,

perhaps this helps: I've also problems with new lines when opening some linux file under windows. Perhaps they use different characters for new line, but I don't know...

Actually, this file was created in linux and when I looked at the raw hex on the hard drive image, the \n's were the only thing where the line breaks were. Also, the ascii symbol printed was definitely that of a newline.

*sigh*

when I looked at the raw hex on the hard drive image, the \n's were the only thing where the line breaks were

I hope you're using that as short-hand for character 10 or 13. If the file actually contains a literal "\n" then there's no way it's going to be interpreted as a newline when it gets printed out.

\n is handled by the print statements when it's part of a string that you have typed into the source, a lot of other situations it isn't done.

On the other hand you already mentioned it just has the little blocks when printed, so you can probably ignore what I just said. I would agree with the previous posters who said that the file could contain the wrong character. Try 10 (0x0A), 13 (0x0D) or both in different combinations (both in the file and in seperate tests printing to the screen) and see which fixes it and then work back from there.

Hahaha, yes \n is shorthand for 10... I'm not stupid enough to type \n in a text file and think it will come out as a newline. And they're definitely 10s and not 13s, both from looking at the hdd image, and from actually interpreting 13s in the kprintf and having that not change anything.

Turns out that it was a bug in kprintf that didn't pass any of the strings passed as arguments through the special character parser. I did this when I wrote it because passing string with special characters that require arguments would print **** from the stack. Looks like I'll just have to strip those out of the passed string before I print it.