c-program questiontype: echoing stdin to stdout

c-program questiontype: echoing stdin to stdout

by Michael Fairbank -
Number of replies: 3

Hi, in an earlier forum post, Richard wrote

CodeRunner's 'run-in-sandbox' AJAX service, which is what the Ace-inline-filter is using, simply sends a complete job to the Jobe server which runs it and returns the results. There's no interactivity possible here. You can supply a text string to be used in lieu of keyboard input but Jobe just writes this to a file and runs the job with stdin redirected to that file. Input is not echoed to standard output so if there are, say, two successive reads from stdin with prompt strings Prompt A and Prompt B, the student will just see the output Prompt A Prompt B all on one line with no apparent input taking place. Unless they're carefully trained on what to expect, they will find this very confusing.

Is there anyway to avoid this behaviour, i.e. to automatically echo the stdin to stdout, so that it is less confusing to students?  It would be good if the "expected" and "actual" strings could match exactly what the students see if they run this C program in their own console (i.e. outside of coderunner), where the stdin comes from their keyboard and is echoed to the console.  Could we have a new question type e.g. "c-program-echo-stdinout" to do this? Or is there an existing solution? Thank you.

In reply to Michael Fairbank

Re: c-program questiontype: echoing stdin to stdout

by Richard Lobb -
The problem is easily solved in Python: the out-of-the-box question type python3_w_input replaces the standard Python input function with one that does as you suggest, echoing standard input to standard output as it is consumed.

With other languages, though, it's harder. We never bothered to develop an equivalent question type in other languages as we teach Python as our first language and after that we expect students to understand files and I/O redirection.

But certainly it can be done. I just wrote a  getchar.c that can be compiled and linked in to replace the library getchar function. Adding that getchar.c to a question as a support file and customising the question to compile that file as well, gives a question that behaves like the following:

The support file getchar.c is the following:

/* A getchar function to replace the standard one, which echoes
 * characters from stdin to stdout as they are consumed.
struct _IO_FILE;
typedef struct _IO_FILE FILE;
extern int fgetc(FILE *__stream);
extern FILE *stdin;
extern int putchar(int __c);
int getchar() {
    int c = fgetc(stdin);
    return c;

The xml export of the question is attached. Note that it's customised, and you have to open the Advanced Customisation section to see how the compileargs parameter is set to compile the added file.

You should be able to do the same sort of thing with scanf, though it will be much harder. You'd probably want to start with the source code for scanf (see here and here) and tweak to do the output as well.

You could of course turn this into a question type. If you do so, could you post it back here, please?

In reply to Richard Lobb

Re: c-program questiontype: echoing stdin to stdout

by Michael Fairbank -
Hi Richard, we did not manage to implement this yet. We have just explained to the students to expect this behaviour for now.

I wonder if there is a clever trick using Unix streams or similar, which means we pass a flag to the jobe server when it runs program code, which forces it to echo all inputs from the input stream to the console, regardless of whatever language it is running? Then instead of doubling up all language question templates (e.g. creating "python3" vs "python3_w_input", and "C" vs "C_w_input") there is just one checkbox in the code-runner question-setting user-interface called "w_input" or similar? It feels to me that the might be a clever global solution to this problem, lurking underneath somewhere, waiting to be discovered?
In reply to Michael Fairbank

Re: c-program questiontype: echoing stdin to stdout

by Richard Lobb -
Yep, it would be nice if there was a better solution. Maybe someone will post something back to this thread in the future.