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. _______________________________________________ Gnucap-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnucap-devel
