equivalent of pipefail in dash shell

Question

Is there some similar option in dash shell corresponding to pipefail in bash?

Or any other way of getting a non-zero status if one of the commands in pipe fail (but not exiting on it which set -e would).

To make it clearer, here is an example of what I want to achieve:

In a sample debugging makefile, my rule looks like this:

set -o pipefail; gcc -Wall $$f.c -o $$f 2>&1 | tee err; if [ $$? -ne 0 ]; then vim -o $$f.c err; ./$$f; fi; 

Basically it runs opens the error file and source file on error and runs the programs when there is no error. Saves me some typing. Above snippet works well on bash but my newer Ubunty system uses dash which doesn't seem to support pipefail option.

I basically want a FAILURE status if the first part of the below group of commands fail:

gcc -Wall $$f.c -o $$f 2>&1 | tee err 

so that I can use that for the if statement.

Are there any alternate ways of achieving it?

Thanks!

Answer 1

I ran into this same issue and the bash options of set -o pipefail and ${PIPESTATUS[0]} both failed in the dash shell (/bin/sh) on the docker image I'm using. I'd rather not modify the image or install another package, but the good news is that using a named pipe worked perfectly for me =)

mkfifo named_pipe tee err < named_pipe & gcc -Wall $$f.c -o $$f > named_pipe 2>&1 echo $? 

See this answer for where I found the info: https://stackoverflow.com/a/1221844/431296

Answer 2

The Q.'s sample problem requires:

I basically want a FAILURE status if the first part of the ... group of commands fail:

Install moreutils, and try the mispipe util, which returns the exit status of the first command in a pipe:

sudo apt install moreutils 

Then:

if mispipe "gcc -Wall $$f.c -o $$f 2>&1" "tee err" ; then \      ./$$f  else       vim -o $$f.c err  fi 

---

While 'mispipe' does the job here, it is not an exact duplicate of the bash shell's pipefail; from man mispipe:

   Note that some shells, notably bash, do offer a    pipefail option, however, that option does not    behave the same since it makes a failure of any    command in the pipeline be returned, not just the    exit status of the first.