@limhoff-r7 to make the API more robust, but minimize impact from refactoring, do you have any recommendations for exposing the failed command or commands?  The method will still have to return true for some definition of success and false for some definition of fail.  Some ideas that come to mind are, for success:  ret true if 1 or more commands succeeded OR true if all commands succeeded.  For fail:  ret false if 1 or more commands failed OR false if all commands failed.  For mixed results, the method could return some not strictly true object like a string of the first failing command or an array or a hash of all failing or succeeding commands.  Obviously there is a trap here in that callers, especially callers from code implemented before this change, may not be checking for actual true, but rather the "implicit true" like with the ol' if run_multiple; do success stuff;end.  Callers could check the length of the array/hash.  This is part of the reason I exposed the 'parse_multi_line' method as I needed a way to get the parsed commands w/o evaluating them for use in the alias plugin and that could be used again for this problem.

A better idea might be to also except a block and let the caller decide what they really want to do.  This is probably much more flexible.  I'll still probably need to check all the existing callers to see if they are using the "implicit true" check since they clearly can't currently be using the block approach.  However there aren't that many spots where we are called as evidenced in the changes in this PR.  Therefore, I guess.

Implementing the && and || now might actually be easier as I can handle the logic pretty easily w/in the lines.each at line 405.  Depending on whether commands are separated by && or || and the return value of the last command run, a return for the overall method is easy to determine