Because of different shell quoting rules, and the fact that LLDB commands often contain spaces, -O is not portable for writing command lines. Instead, we should use explicit lldbinit files.
Unless we create a utility that extracts lines based on prefixes and outputs them to a temporary file, I don't have any great ideas.
FWIW I actually find it easier to read this way, the interaction between the various command line options makes it pretty confusing to follow the order in which the various commands are executed. combining -O, -o, -S, and -s makes it quite hard to figure out what commands are actually being executed and in what order.
Another advantage to having the commands be in their own file is that it's easy to reproduce the failure by just running lldb -s script.lldbinit.
I'd even go so far as to say that maybe the .test file should be the source code + check lines, and each of the 3 test cases should be a separate script file with all the commands together in one file. It could use the command source command to avoid duplication. So, for example, stop-hook-1.lldbinit could be something like:
target stop-hook add -f stop-hook.c -l 30 -e 34 -o "expr ptr" command source stop-hook-common.lldbinit
I do agree it's slightly easier to read this way. I was conflicted while writing the tests between readability and conciseness. I think this is a good compromise.
I do prefer to have the check lines with the commands rather than with the source code though. The output is the result of the commands and sometimes it's not as clear what it refers to in the source.