run_script continues after not a recognized command

Filing as a separate issue, but related to #1185 and #1207. Currently run_script also suffers from not seeing the error caused by a command that doesn’t exist. A similar issue happens with unknown or incorrect arguments to a command. This would also occur in startup commands.

For example, with first_app.py, using this as a script

speak a
youdontsay b
speak --dummy 
speak c

does not stop execution on the second or third command and keeps running. Most users, I think, would expect a script to stop if it encounters an error situation like a command that doesn’t exist or badly formed arguments and would be surprised to see “c” printed.

When a command that does not exist is encountered now, onecmd() calls default() which just prints a message with perror(). But this means that neither runcmds_plus_hooks() nor _test_transcript() in transcript.py are aware that the failure situation has occurred and so they continue to the next command.

[crotwell]

Bash, for example, continues after an error because the next line can potentially use the exit code of the previous and do something appropriate on error. There is also set -e to tell bash to exit on the first error.

I am not suggesting cmd2 scripts should have sophisticated error handling features, keeping it simple is best for run_script. But I would humbly suggest that in the absence of error handling, “halt on first error” is the least bad strategy. Your call of course.

[chrysn]

I agree @crotwell in that a set -e mode would be desirable for scripting (maybe enabled with set stop_script_on_error True). Ideally, that would halt script processing both on unknown commands and on commands that raise an exception.