run_script continues after not a recognized command

[crotwell]

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.

[kmvanbrunt]

run_script is for basic command scripts, which have no logic. They're no more advanced than running multiple command lines in a row. Great for automation, but not for things which can fail. Without added logic, Windows batch files and Bash scripts also don't stop if an invalid command is run.

If you need something more powerful, consider using Python scripts with the run_pyscript command.

https://cmd2.readthedocs.io/en/stable/features/scripting.html

[jayrod]

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.

Actually in bash scripting this is exactly what happens. I just tried this out.

#/bin/bash

echo 'Works'
randome_command_not_exists
ls -l /tmp

The first and the third commands work like expected and there is an error for the second one. So it doesn't make sense to not show an error but continuation seems perfectly normal

[kmvanbrunt]

Closing since run_script is functioning as designed.

[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.