0

It is likely that this type of scenario is not possible as I have not found this behavior documented anywhere but was curious if anyone had any tricks to accomplish something like this. Is it possible to determine the contents of the stdin buffer for a program before the user actually hits enter to submit the data?

I am attempting to do this as I have built a simple terminal chat program which sends messages from one terminal to another for easy communication. The issue we have run into is that since incoming messages and outgoing messages appear in the terminal together, if a user is typing a message when a message is received from the other end it distorts the display and appends the typed message at the end of newly received message. It would be convenient if there was a way to check the contents of the buffer and act accordingly, but I am not sure if this is possible without a gui type interface level.

majic bunnie
  • 1,395
  • 2
  • 10
  • 21
  • Duplicate to http://stackoverflow.com/questions/421860/c-c-capture-characters-from-standard-input-without-waiting-for-enter-to-be-pr? – pmod Oct 22 '11 at 21:59
  • 2
    Your question is not about stdin, but about reading a tty. These are two very different things. Check out ncurses. – William Pursell Oct 22 '11 at 22:03
  • Thank you for clarifying, indeed that is what I am attempting to do, I will check out ncurses functionality. – majic bunnie Oct 22 '11 at 22:08
  • To expand a bit on William's remark: c the language does not have a notion of buffered input, nor does the standard library. Accordingly how one works with a possibly buffered input depends on the system that is offering it to you. – dmckee --- ex-moderator kitten Oct 23 '11 at 02:39

1 Answers1

0

Search for 'kbhit.c' on this page: http://pwilson.net/sample.html

Pete Wilson
  • 8,610
  • 6
  • 39
  • 51
  • Thanks, this looks great as well, should do the trick for me. – majic bunnie Oct 22 '11 at 22:26
  • 1
    That is utterly **horrible** code. Two immediate errors that stand out: (1) the use of the wrong return type (`unsigned char` rather than `int`) forces "no character" and the null character to share the same value, making it impossible to detect Ctrl-@/Ctrl-Spacebar, and (2) the "waiting" version of the function enters a CPU-hogging retry loop with `usleep` rather than using `select`/`poll` or blocking mode. – R.. GitHub STOP HELPING ICE Oct 23 '11 at 02:19