To force output to the screen, please see the first section below. The second and third options below are also good for debugging program crashes like these.

Using printf with fflush (refinement of Vishal Kumar's answer)

Vishal Kumar's answer worked for me, but I had to do a little research to find out how to use fflush. I had a problem where my program was crashing "in the middle" of a printf statement which did not make sense. Here is my refinement of his answer. In cases where a debugger is difficult to use (e.g. multithreading), you can use fflush after every printf (or fprintf) statement. For example, "pepper your code" with:

... // code
printf("Part 1 executed successfully");
fflush(stdout); // flushes the stdout buffer
... // further code
printf("Part 2 executed successfully");
fflush(stdout);
... // repeat as necessary

Run, observe the output, and put more print statements between the last statement that prints, and the first statement that doesn't print, until you isolate the problem.

Debugger

If you are able to use a debugger, it is a more efficient choice than peppering your code with output statements as described above, but there are cases where you have to resort to that.

Valgrind

If you are using Linux (which I gather you are not because it is in MS Visual C++), valgrind is another option to see where your code is crashing (and for detecting memory leaks). If your code is compiled for debug, if your program is called "myProgram", you can just call from the terminal window as follows:

valgrind myProgram

On many systems printf is buffered, i.e. when you call printf the output is placed in a buffer instead of being printed immediately. The buffer will be flushed (aka the output printed) when you print a newline \n.

On all systems, your program will print despite the missing \n as the buffer is flushed when your program ends.

Typically you would still add the \n like:

printf ("%s\n", a);

An alternative way to get the output immediately is to call fflush to flush the buffer. From the man page:

For output streams, fflush() forces a write of all user-space buffered data for the given output or update stream via the stream's underlying write function.

Source: http://man7.org/linux/man-pages/man3/fflush.3.html

EDIT

As pointed out by @Barmar and quoted by @Alter Mann it is required that the buffer is flushed when the program ends.

Quote from @Alter Mann:

If the main function returns to its original caller, or if the exit function is called, all open files are closed (hence all output streams are flushed) before program termination.

See calling main() in main() in c

Like @thejh said your stream seems to be buffered. Data is not yet written to the controlled sequence.

Instead of fiddling with the buffer setting you could call fflush after each write to profit from the buffer and still enforce the desired behavior/display explicitly.

printf( "Enter first integer\n" );
fflush( stdout );
scanf( "%d", &i1 );

for (nc=0; getchar() !=EOF; ++nc);

the ';' at the end of the line is perhaps not what you want, because of it the body of the for is empty

so printf("%d\n", nc); is executed only one time, not several, and for that you need first to go out of the for, so to reach EOF

What is your OS, what are you doing to have EOF ?

If you never reach EOF it is normal to have nothing print

If you are under Linux/Unix you can do echo blahblah | ./yourprog and yes in that case you will print 9 (because of the newline, 8 if echo -n blahblah)

Under Windows do not execute your code through codeblocks, execute it directly in a terminal, codeblocks and other IDE have unexpected behavior on the input/output

This will (hopefully) explain this specific problem in main and perhaps the overriding problem. The output buffer is not "flushed" until a new line (or explicit flush). The answer provided here explains it. If the added debugging printfs are "not executing" it could be for the same reason, since the first "\n" that is encountered would likely be after "MISSPELLED WORDS". Changing this printf("start main"); to this printf("start main\n"); will change the result.

Here is the output, of your program:

The text from printf ("test"); is printed and you can see it before the line shubham@shubham-pc:~$

Since there is no \n in your program, a newline is not printed at end and hence the default line of console gets printed after it

To solve this your program should look like:

#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>

int main()
{
    printf("%s \n","test");
    return 0;
}

The thing I've done here is that, I used a format string (%s) to print test and added a newline (\n) after it.

Here is the output after the edits:

First, main returning void is illegal, please activate warning. Secondly, one of your printf lacks a \n which may explain why it isn't flushed into your terminal by default.

Output is buffered.

stdout is line-buffered by default, which means that '\n' is supposed to flush the buffer. Why is it not happening in your case? I don't know. I need more info about your application/environment.

However, you can control buffering with setvbuf():

setvbuf(stdout, NULL, _IOLBF, 0);

This will force stdout to be line-buffered.

setvbuf(stdout, NULL, _IONBF, 0);

This will force stdout to be unbuffered, so you won't need to use fflush(). Note that it will severely affect application performance if you have lots of prints.

printf 'ABC\ctest'

You've hit upon one of the unspecified parts of the printf command, whose behaviour varies from implementation to implementation. You're putting the \c in the wrong place.

If you read the Single Unix Specification's description of printf carefully, you will see that \c is not listed in the list of escape sequences that are defined for the format string (the first argument to the command). Rather, it is defined as an extra escape sequence that is recognized when given in an argument string that is to be formatted by the %b format specifier.

In other words:

• printf '%b\n' 'ABC\ctest' has a well specified behaviour. The \c causes everything remaining (including the newline in the format string) to be ignored.
• printf '%s\n' 'ABC\ctest' has a well specified behaviour. The \c is not an escape sequence in the first place.
• printf '\c' does not have a well specified behaviour. The SUS is simply silent upon what \c is, not listing it as an escape sequence but also not saying in its File Format Notation section that such a sequence is never an escape sequence.

How different shells behave in response to this non-conformant format string varies quite significantly. Here are the Debian Almquist, Bourne Again, FreeBSD Almquist, Korn '93, and Z shells' reactions (with %s showing where no newlines have been emitted):

% dash -c "printf 'ABC\ctest\n'"
ABC\ctest
% bash -c "printf 'ABC\ctest\n'"
ABC\ctest
% sh -c "printf 'ABC\ctest\n'"
ABC%
% ksh93 -c "printf 'ABC\ctest\n'"
ABCest
% zsh -c "printf 'ABC\ctest\n'"
ABC%
%

The builds of the MirBSD Korn and PD Korn shells that I have do not have a printf built-in command. The FreeBSD non-built-in printf does this:

% /usr/bin/printf 'ABC\ctest\n'
ABC%
%

Adding to the fun is that the doco for the various shells is sometimes highly misleading and even sometimes downright erroneous. For examples:

• The Z shell doco only recently started to give a correct description of what \c does, and lists it (via its doco for echo) as an escape sequence allowed in format strings. (It was incorrect until 2017, the doco neither agreeing with the SUS nor describing what the Z shell actually did.)
• The Korn '93 shell doco gives a description that is in line with the SUS, but it is not (as can be seen in the aforegiven) what it actually does when \c is in the format specifier. It, too, documents \c as an escape sequence for the format string. Its behaviour is clearly a bug.
• The doco for the Bourne Again shell and the doco for the Debian Almquist shell give a description of \c that matches the SUS and explicitly list it in relation to %b (in the case of the Bourne Again shell more clearly than it does now up until 2016) and not in a general list of escape sequences for printf format specifiers. These shells do not provide this as an extension to the standard.
• The FreeBSD Almquist shell doco defers to the FreeBSD external printf command manual, whose description of \c is in line with the SUS. It explicitly lists it as an escape sequence allowed in format strings, and its actual behaviour is as documented in the user manual.

The FreeBSD Almquist shell and (recent) Z shell are the only shells, here, that both document allowing \c as an escape sequence in format strings (an extension to what is defined by the standard) and actually behave as they are documented.

Ironic further reading

• Why is printf better than echo?