Question

General use case

I am trying to implement a basic shell.

Description

I need to read user input until some delimiters are pressed so a corresponding action can be performed. Those delimiter could be a single ‘a’, a single ‘b’ or a single ‘c’.

An input example would look like this (where > is the shell prompt):

> 111-222-333-444a
Ok, '111-222-333-444' entered

Why do I want inline delimiter instead of ‘new-line’ delimiter?

Because I would like to listen to keyboard event such as ‘up-arrow’ to erase the current command and print the last command (implementing a history feature).

Because I would like to listen to keyboard event such as ‘tabulation’ to automaticly complete the current command (implementing auto-completion feature).

What I have so far

Up to now, my code looks like this:

bool done = false;
char c;
while (!done && std::cin.get(c))
{   
    switch (c)
    {
    case 'a':
        // Do something corresponding to 'a'
        done = true;
        break;

    case 'b':
        // Do something corresponding to 'b'
        done = true;
        break;

    case 'c':
        // Do something corresponding to 'c'
        done = true;
        break;

    default:
        // buffer input until a delimiter is pressed
        break;
    }
}

However, the loop seem to be executed only after the ‘new-line’ key have been pressed. This behaviour kill the interactive essence of the user input.

What is the question?

I know std::ostream is buffered so content is not write to disk until some event occured but what about std::istream. Is it buffered? If yes, how is it and what are my option to bypass this behaviour?

Also, I’ve tagged this question as ‘homework’ because, event if it is not a school exercice, it is an exercise I am trying to do by myself and I do not want to only pick a library that implement all this stuff.

Answer 1

If you are on a POSIX operating system, you can set the terminal to be unbuffered using the functions and structures declared in termios.h. Basically you need to disable canonical input, and setup the terminal for non-canonical mode. These are some links that can help you with understanding the difference between the two terminal modes:

1. Noncanonical Input (from the libc manual)

   In non-canonical input mode, the special editing characters such as ERASE and KILL are ignored. The system facilities for the user to edit input are disabled in noncanonical mode, so that all input characters (unless they are special for signal or flow-control purposes) are passed to the application program exactly as typed. It is up to the application program to give the user ways to edit the input, if appropriate.

2. Canonical vs. non-canonical terminal input

   For canonical input – think shell; actually, think good old-fashioned Bourne shell, since Bash and relatives have command-line editing. You type a line of input; if you make a mistake, you use the erase character (default is backspace, usually; sometimes DEL) to erase the previous character … For non-canonical input – think vi or vim or … you press a character, and it is immediately available to the program. You aren’t held up until you hit return.

3. Description of Terminal Interface

   This chapter describes a general terminal interface that is provided to control asynchronous communications ports. It is implementation-dependent whether it supports network connections or synchronous ports or both.

In essence though, the issue you’re encountering is not with the C++ iostream interface itself, but rather has to-do with how the controlling terminal that the C++ iostream interface is reading from has been setup. Thus taking advantage of unbuffered I/O is going to be a platform-dependent operation, and will differ dependending on whether you’re using Windows, or an actual POSIX-compliant platform (this includes POSIX-environments for Windows such as Cygwin).

If you find that messing around with the terminal settings is too much of a problem, you can also look into a cross-platform curses programming library such as PDCurses that will abstract most of the complexities of the underlying terminal types.