Re: [Gnucap-devel] [Child Process unable to receive input from a file(script)]

[al davis]

On Thursday 26 June 2014, Rishabh Yadav wrote:
> So,in case a script of nested conditional commands in a file
> is executed then is_file() is true for outermost level
> if/elif/else command.But when this if/elif/else command
> calls a nested command then it does so via CMD::command()
> method and there is_file() returns false and hence get_line
> waits for input from user within the interpreter.

You should use CMD::cmdproc() not CMD::command().

CMD::command() is a low level function for internal use.  It has 
no knowledge of any files, so it doesn't work for commands that 
require more input.  The argument is a std::string.  It is 
intended for use when you don't have a stream, you are building 
up the command as a string, which has to be converted to a CS to 
pass on.

CMD::cmdproc() is a higher level function intended for user 
input with parsing and error handling.  The argument is a "CS" 
object (command_stream).

The problem you are having is that when you use CMD::command(), 
the connection to the input stream is lost.  There is nothing 
passing it in.

> I strongly believe we should incorporate this change in ap.h
> as I was told by the Felix that he also faced the similar
> problem. Let me know your suggestions and possible changes
> we can make to fix this.

I don't see a need for a change to ap.h and ap*cc.  

Perhaps CMD::command() should be eliminated.  That whole file 
should be reviewed.

So, I ask myself .. why was it created?  Answer: to simplify the 
interface for commands that call a collection of other commands.  
It doesn't work to pass the stream in the usual way because 
doing so would clobber it.  Also, avoiding accounting and the 
like makes the command look like a single command, and not the 
sum of its parts.  That is needed, so CMD::command stays.