You can test your program using (with a POSIX shell) here documents.
First compile your source code mycode.c
into a binary mybin
with
gcc -std=c99 -Wall -Wextra -g mycode.c -o mybin
(it could be clang
or cc
instead of gcc
)
then run mybin
with a "here document" like
./mybin << EOF
here is my
input
EOF
You could also use input redirection. Make some file myfile.txt
and run ./mybin < myfile.txt
You could even run your program on its own source code: ./mybin < mycode.c
And the input could even come from some pipe, e.g. ls * | ./mybin
BTW, what you are observing is that stdin
, when it is a terminal, is line-buffered. See this answer (most of it should apply to MacOSX).
Notice that your code is incorrect: you are missing an #include <stdio.h>
near the top of the file, and your main
should really be int main(int argc, char**argv)
(BTW you could improve your program so that when arguments are given, they are file names to be read). At last the ending printf
would surely show -1 which is generally the value of EOF
Also, it is much better to end your printf
format control string with \n
or else use appropriately fflush(3)
Notice that end-of-file is not an input (or a valid char
), it is a condition on some input file stream like stdin
, and the getchar(3) function is specified to return EOF
which is an int
outside of the range of char
(on my Linux system EOF
is -1 because char
-s are between 0 and 255 included). You might test end-of-file condition after some input operation (never before!) using feof(3)
A terminal in usual cooked mode is handled by the kernel so that when you press Ctrl D an end-of-file condition is triggered on the file descriptor (often STDIN_FILENO
i.e. 0) related to that terminal.