Not sure if this is an appropriate question, but just recently I've noticed that when I run a C++ program in the terminal when it exits it has a % sign after the last output. For example a hello world program says "hello world%". What is this and how do I get rid of it? I'm on OS X, shell is zsh. Unless I am crazy it has never done this until now.
There are two possibilities that I can think of off hand:
1) You aren't printing a carriage return, so the % prompt appears at the end of the printed text instead of on the next line. (Is the % your standard prompt in the shell?)
2) You are printing past the end of a buffer and getting a random character as a result.
I'd guess #1 based on what you describe, but both could cause the behavior.
Related
I tried to print a line that asks for input from the user, get the input, then print again some line. The problem is that the white space at the end of the first printed line is printed not at the end of the line, but rather at the beginning of second printed line, after i get the input.
I'm completely new to C++ so I couldn't really try much, but i tried printing the code without the part that prompts the input from the user, and it prints the space just fine, but when i add std::cin << input; the space get's sent to the beginning of the second line.
My code:
int input;
std::cout << "Enter your favorite number between 1 and 100: ";
std::cin >> input;
std::cout << "Amazing... That's my favorite number too... wow..." << std::endl;
I want the output to be
Enter your favorite number between 1 and 100: //some input
Amazing... That's my favorite number too... wow...
(note the space before //some input)
Instead i get
Enter your favorite number between 1 and 100://some input
Amazing... That's my favorite number too... wow...
(note the space before Amazing)
Edit: I'm using Clion if it could be connected. Also, I tried to run the executable on powershell and it worked as expected, without the problem, so this has something to do with the Clion terminal. Also, i'm using windows 10 as my OS.
Second Edit: add my findings on my answer.
This seems to be a problem with buffered input of Clion. See this issue: https://youtrack.jetbrains.com/issue/CPP-7437
When you are using CLion, You can try disabling PTY (Help | Find Action > type "Registry" > open Registry > find and disable the run.processes.with.pty option)
CLion moving space into new line
Are you sure about that? I tried both in online shell and on local machine and it works as expected.
After checking I found out that this occurs only on the Clion Run terminal, so this has something to do with it exclusively. I'm currently trying to mess around with the settings. I will post a solution and an explanation here if I find it.
Edit: as mentioned in one comment, it could be the issue mentioned here https://youtrack.jetbrains.com/issue/CPP-7437.
In any case it is a Clion related problem exclusively, and not a C++ problem.
This problem is only applicable for the second line, if you leave that line empty then the problem will be fixed. Don't know about C++ but for C before the print statement you have to add: printf("\n");
After last week's updated to Xcode 8.3, in a C/C++ program the output from a printf statement no longer appears on the screen without a newline. Thus I can't prompt for the user to enter a number, and have them type in that number on the same line following the input prompt.
Neither flushing the output buffer [fflush(stdout) or cout << endl] nor setting the output buffer to NULL [setbuf(stdout, NULL)] addresses this problem, but rather is a question specifically about Xcode 8.3 seemingly being broken.
With the scanf commented out, the output of the program below is:
Enter a value for x: Value of x is: 0
With the scanf in place, the output from the first printf never shows up. If you go ahead and type in a value and press enter, only then does it show up. Output is:
3
Enter a value for x: Value of x is: 3
Full test program is here:
#include <iostream>
using namespace std;
int main() {
int x=0;
printf("Enter a value for x: ");
//scanf("%d", &x);
printf("Value of x is: %d\n", x);
return 0;
}
My work-around has been to revert back to Xcode 8.2.1, downloaded from developer.apple.com/xcode/downloads/
8.3.2 was announced last night and addresses this supposedly:
It is standard behavior in C for stdout to be flushed when an input function is called, such as scanf(), regardless of whether a newline was output prior to the call or not. This ensures that all appropriate output is displayed before the input operation takes place. Therefore, the update might have broken something in Xcode. Although I'm not currently sure what the exact nature of the problem is, a (temporary) workaround is to run your application on the command line. This has worked for my projects. It also reveals that this problem is with the Xcode output window, and not the compiler or something else.
In response to tell's comment: no, flushing stdout does not correct the issue within Xcode. This implies even more strongly to me that the issue is definitely in the Xcode interface itself. When running the application from the command line, calls to fflush() work as expected.
Also, printing to stderr makes no difference from within Xcode. Basically, stdout should be flushed in this case without appealing to stderr or any other gimmicks because the OP is calling scanf(). It works perfectly from the command line... just not in the Xcode output window.
And please note this this question is not a duplicate: it has nothing to do with anyone's misunderstanding of how C input and output work, and everything to do with the fact that a recent update to Xcode broke something.
EDIT:
Thanks, joe_04_04. The update certainly seems to have fixed the problem.
I have been making a program that outputs each character before a given one to the screen, but... I've been doing it with Brainfuck! :)
I would like to be able to input a character, and see all the characters that come before it. The code I have so far only outputs a space and then waits for the next key press before exiting.
++++++++
[>+++++++++<-]>.>++++++++++[>++++++++++<-]>+.+++++++..+++.>
++++++++[>++++<-]>.>++++++++[>++++++++++++<-]>+.+++ ++++++++++.
----------.>++++++++[>++++<-]>.>++++++++++
[>++++++++<-]>+++++++.
++++++++++++++.>+++++++++[>++++++++++++<-]>.---------.>
++++++++++[>+++++++++++<-]>+.--.--------.>+++
[>++++++++++<-]>+++.>++++++++++
..>+[,[>+>+<<-][>>-<<+>>]>[[-.]<]],
I've tried for ages to figure out what's wrong with this code, but everything I've done has messed it up.
Works for me, try this BF interpreter
------[>++++++++++<+]>--.+<------[>---<+]>.
I have C code like this:
#include<stdio.h>
int main()
{
printf("Hey this is my first hello world \r");
return 0;
}
I have used the \r escape sequence as an experiment. When I run the code I get the output as:
o world
Why is that, and what is the use of \r exactly?
If I run the same code in an online compiler I get the output as:
Hey this is my first hello world
Why did the online compiler produce different output, ignoring the \r?
\r is a carriage return character; it tells your terminal emulator to move the cursor at the start of the line.
The cursor is the position where the next characters will be rendered.
So, printing a \r allows to override the current line of the terminal emulator.
Tom Zych figured why the output of your program is o world while the \r is at the end of the line and you don't print anything after that:
When your program exits, the shell prints the command prompt. The terminal renders it where you left the cursor. Your program leaves the cursor at the start of the line, so the command prompt partly overrides the line you printed. This explains why you seen your command prompt followed by o world.
The online compiler you mention just prints the raw output to the browser. The browser ignores control characters, so the \r has no effect.
See https://en.wikipedia.org/wiki/Carriage_return
Here is a usage example of \r:
#include <stdio.h>
#include <unistd.h>
int main()
{
char chars[] = {'-', '\\', '|', '/'};
unsigned int i;
for (i = 0; ; ++i) {
printf("%c\r", chars[i % sizeof(chars)]);
fflush(stdout);
usleep(200000);
}
return 0;
}
It repeatedly prints the characters - \ | / at the same position to give the illusion of a rotating | in the terminal.
The program is printing "Hey this is my first hello world ", then it is moving the cursor back to the beginning of the line. How this will look on the screen depends on your environment. It appears the beginning of the string is being overwritten by something, perhaps your command line prompt.
The '\r' stands for "Carriage Return" - it's a holdover from the days of typewriters and really old printers. The best example is in Windows and other DOSsy OSes, where a newline is given as "\r\n". These are the instructions sent to an old printer to start a new line: first move the print head back to the beginning, then go down one.
Different OSes will use other newline sequences. Linux and OSX just use '\n'. Older Mac OSes just use '\r'. Wikipedia has a more complete list, but those are the important ones.
Hope this helps!
PS: As for why you get that weird output... Perhaps the console is moving the "cursor" back to the beginning of the line, and then overwriting the first bit with spaces or summat.
\r move the cursor to the begin of the line.
Line breaks are managed differently on different systems. Some only use \n (line feed, e.g. Unix), some use (\r e.g. MacOS before OS X afaik) and some use \r\n (e.g. Windows afaik).
As amaud576875 said, the \r escape sequence signifies a carriage-return, similar to pressing the Enter key. However, I'm not sure how you get "o world"; you should (and I do) get "my first hello world" and then a new line. Depending on what operating system you're using (I'm using Mac) you might want to use a \n instead of a \r.
This is from antiquated technology: The old fashion typewriter style of printer. There was a roller (platen) that advanced the paper and a print head that hammered a metal key against an ink fabric.
\r Return the print head to the left side.
\n Advance the platen one line.
If the \n was not issued, you would type over what was on a line (used mostly for underlining text).
To answer the part of your question,
what is the use of \r?
Many Internet protocols, such as FTP, HTTP and SMTP, are specified in terms of lines delimited by carriage return and newline. So, for example, when sending an email, you might have code such as:
fprintf(socket, "RCPT TO: %s\r\n", recipients);
Or, when a FTP server replies with a permission-denied error:
fprintf(client, "550 Permission denied\r\n");
It is quite useful, when you are running on the unix platform, and need to create a text file
which will be opened on the dos platform.
Unix uses '\n' as its line terminator, and dos uses '\r\n' as its line terminator, so you can use it to create a dos text file.
I compiled on Ubuntu a program that was developed for (and works on) Windows. On Ubuntu, I see this code:
string s = values_[9];
cout << s << endl;
cout << s << "x\n";
producing this output:
high
xigh
The expected output for the second line is "highx". I know that the value of values_[9] is originally read from a file (written on Windows). Printing other strings seems to work normally.
What's going on here?
Run the command with its output piped through cat -A. Probably either the value of s, or the output produced by endl is giving you a '\r' character, which typically sends the cursor back to the beginning of the line.
EDIT: On further thought, the stray '\r' is almost certainly in s, not in the output produced by endl. I had thought there might be some funny locale stuff going on, but having s equal to "high\r" explains the symptoms.
EDIT2: If your system doesn't have cat -A (it's a GNU extension), try cat -v or, if you're desperate, od -c.
The string you're printing has a carriage return '\r' in it. What's happening is that you're printing high, then the carriage return, which puts the cursor back on the start of the line. Then, when you print the x, it overwrites the first letter on the line.
You should either remove the carriage return from the source file (e.g. with dos2unix(1) or many other options), or change your code to strip the carriage return after reading the file in.
What is probably happening, is that there is a \r in values_[9].