Hi Bruce, Here's a proposed change for checking for syntax and other errors. (This would make v. 1.2.7. I might be willing to toss in a few more things too). First, and mostly, add '&status' variable to hold status flags from commands. The values of &status could be (open for suggestion): 0.0 no error (see below) 1.0 benign warnings (eg, 'unknown keyword' for commands) 2.0 more serious warnings: syntax errors, evaluation errors (divide-by-zero), or a command stopped prematurely for some other reason (eg, "can't find an array for energy"). 3.0 severe warnings: hitting an internal program limit, 'file not found', and so on. Those could be changed or expanded, to say, be along the lines of: 1.1 'unknown keyword' 1.2 'data out of order for spline/pre_edge....' 1.3 fit couldn't determine error bars.... 2.0 syntax error during parsing 2.1 evaluation error (eg, divide-by-zero) 2.2 can't find enough arrays to process command and so on. That's mostly a matter of how detailed of the value should be as opposed to parsing the strings that would be in the echo buffer. I'd imagine that more &status values would be better than parsing the messages. I would also propose that &status is _not_ automatically set to 0 prior to each command. This would mean that the user / script writer would have to explicilty set &status = 0 as a way to 'clear warning messages'. That would lead to a wrapper around ifeffit that does this (ignoring the saving,logging of the command): wrap_ifeffit(command_string) { set &status to 0 execute command_string check &status react to &status (maybe look at echo buffer at this point) } on the whole, that first 'set &status to 0' doesn't seem so bad. The important reason to _not_ automatically reset &status is so that warnings stick even when multiple commands and macros are run. So, the main questions to you, Sam, and anyone else who's interested in writing extended scripts / programs are: Is this an OK approah? How fine-grained should the values of &status be? --Matt