I'm really slammed at work this week, but will take a look this weekend if no one else does.

Thanks @rpalo. I wonder if we could guard against a couple of complexities here. bash -c "false" returns the status of the last (in this case, only) command. So bash -c "false ; true" returns true, as does bash -c "false | true". If our code needs the command that false represents to be true then this could lead to confusion.

We could add something like:

To capture the status code of any failing command that is not in a pipe use -e, and if pipes are used consider -o pipefail too.

run bash -e -o pipefail -c "foo | wc -l"
# If foo fails then $status will be foo's exit code

If we wanted further examples (although this could be beyond scope and perhaps in a "defensive BASH" wiki page like this):

run bash -e -o pipefail -c "false | wc -l"  
# $status is 1

bash -e -c "false | wc -l"
# $status is 0

Sorry I didn't get to this this weekend; got slammed with another project. Will try to take a look later today.

@mbland agreed, and here be dragons! I'm happy to those points and some subshell guidance to the examples wiki separately in order to get this merged

What do you think about something like this:

You may also find it useful to pipe commands together. To accomplish
this with the run helper, you will need to wrap the pipe in bash -c command:

@test "invoking foo displays 3 lines of output" {
  run bash -c "foo | wc -l"
  [ "$status" -eq 1  ]
  [ "$output" -eq 3  ]
}

Keep in mind that the return code of bash -c is, by default the return
code of only the last command. Thus, if there is a failing command somewhere
in the pipeline, but the final command exits with a 0 status, this could lead to
unexpected results. To capture the status code of any failing command that is
in a pipe, use the option: -o pipefail. To capture the failing exit codes of
any other non-pipeline commands, use the -e option.

run bash -e -o pipefail -c "foo | wc -l"
# Will fail if foo's exit code is non-zero

However, this may be an unwanted result if foo is a script or function
that contains pipes of its own along with its own error handling.
Alternately, if your script reads from standard input, consider using
run within the pipeline.

echo "foo" | run my-script

I'm new doing pull requests. Is it better that I share ideas here as a comment or just commit another draft?

That looks great @rpalo - fine to discuss here before updating PR too.

If you commit those changes to your branch this PR will update and we'll get it merged! 👍

Great, thanks! Let me know if you see anything else that you'd like me to adjust.

Hi @rpalo, sorry...was really wiped from work, taking longer to recover than anticipated, and fighting off a cold in the process. Will do my best to get to this in the next day or two. (Not that I don't trust @sublimino's judgment, but I owe it some attention, too.)

Oh, don't even stress about it at all. I just wanted to make sure everything was all good. Take care of yourself!

Sorry for the delay. Burning through the backlog now.

After thinking through and responding to mbland/go-script-bash#243, I'm thinking the right suggestion is to promote pushing a pipeline into its own function or script as the cleanest solution.

I'm also pretty sure that piping input into run won't set $output, etc. correctly, just as piping into a while loop creates a subshell that can't assign to variables in the parent's scope.

If we do stick with the recommendations as-is, we'll need test cases.

Thoughts?

Actually, I think you're right, putting the piping into a function makes it way easier to handle. I'll take a look at those changes when I get a minute.

Since this has become somewhat stale, we should see what we can salvage via #366