Get exit status of process that's piped to another

Question

I have two processes foo and bar, connected with a pipe:

$ foo | bar

bar always exits 0; I'm interested in the exit code of foo. Is there any way to get at it?

Answer 1

bash and zsh have an array variable that holds the exit status of each element (command) of the last pipeline executed by the shell.

If you are using bash, the array is called PIPESTATUS (case matters!) and the array indicies start at zero:

$ false | true
$ echo "${PIPESTATUS[0]} ${PIPESTATUS[1]}"
1 0

If you are using zsh, the array is called pipestatus (case matters!) and the array indices start at one:

$ false | true
$ echo "${pipestatus[1]} ${pipestatus[2]}"
1 0

To combine them within a function in a manner that doesn't lose the values:

$ false | true
$ retval_bash="${PIPESTATUS[0]}" retval_zsh="${pipestatus[1]}" retval_final=$?
$ echo $retval_bash $retval_zsh $retval_final
1 0

Run the above in bash or zsh and you'll get the same results; only one of retval_bash and retval_zsh will be set. The other will be blank. This would allow a function to end with return $retval_bash $retval_zsh (note the lack of quotes!).

Answer 2

There are 3 common ways of doing this:

Pipefail

The first way is to set the pipefail option (ksh, zsh or bash). This is the simplest and what it does is basically set the exit status $? to the exit code of the last program to exit non-zero (or zero if all exited successfully).

$ false | true; echo $?
0
$ set -o pipefail
$ false | true; echo $?
1

$PIPESTATUS

Bash also has an array variable called $PIPESTATUS ($pipestatus in zsh) which contains the exit status of all the programs in the last pipeline.

$ true | true; echo "${PIPESTATUS[@]}"
0 0
$ false | true; echo "${PIPESTATUS[@]}"
1 0
$ false | true; echo "${PIPESTATUS[0]}"
1
$ true | false; echo "${PIPESTATUS[@]}"
0 1

You can use the 3rd command example to get the specific value in the pipeline that you need.

Separate executions

This is the most unwieldy of the solutions. Run each command separately and capture the status

$ OUTPUT="$(echo foo)"
$ STATUS_ECHO="$?"
$ printf '%s' "$OUTPUT" | grep -iq "bar"
$ STATUS_GREP="$?"
$ echo "$STATUS_ECHO $STATUS_GREP"
0 1

Answer 3

This solution works without using bash specific features or temporary files. Bonus: in the end the exit status is actually an exit status and not some string in a file.

Situation:

someprog | filter

you want the exit status from someprog and the output from filter.

Here is my solution:

((((someprog; echo $? >&3) | filter >&4) 3>&1) | (read xs; exit $xs)) 4>&1

the result of this construct is stdout from filter as stdout of the construct and exit status from someprog as exit status of the construct.

---

this construct also works with simple command grouping {...} instead of subshells (...). subshells have some implications, among others a performance cost, which we do not need here. read the fine bash manual for more details: https://www.gnu.org/software/bash/manual/html_node/Command-Grouping.html

{ { { { someprog; echo $? >&3; } | filter >&4; } 3>&1; } | { read xs; exit $xs; } } 4>&1

Unfortunately the bash grammar requires spaces and semicolons for the curly braces so that the construct becomes much more spacious.

For the rest of this text I will use the subshell variant.

---

Example someprog and filter:

someprog() {
  echo "line1"
  echo "line2"
  echo "line3"
  return 42
}

filter() {
  while read line; do
    echo "filtered $line"
  done
}

((((someprog; echo $? >&3) | filter >&4) 3>&1) | (read xs; exit $xs)) 4>&1

echo $?

Example output:

filtered line1
filtered line2
filtered line3
42

---

Note: the child process inherits the open file descriptors from the parent. That means someprog will inherit open file descriptor 3 and 4. If someprog writes to file descriptor 3 then that will become the exit status. The real exit status will be ignored because read only reads once.

If you worry that your someprog might write to file descriptor 3 or 4 then it is best to close the file descriptors before calling someprog.

(((((exec 3>&- 4>&-; someprog); echo $? >&3) | filter >&4) 3>&1) | (read xs; exit $xs)) 4>&1

The exec 3>&- 4>&- before someprog closes the file descriptor before executing someprog so for someprog those file descriptors simply do not exist.

It can also be written like this: someprog 3>&- 4>&-

---

Step by step explanation of the construct:

( ( ( ( someprog;          #part6
        echo $? >&3        #part5
      ) | filter >&4       #part4
    ) 3>&1                 #part3
  ) | (read xs; exit $xs)  #part2
) 4>&1                     #part1

From bottom up:

1. A subshell is created with file descriptor 4 redirected to stdout. This means that whatever is printed to file descriptor 4 in the subshell will end up as the stdout of the entire construct.
2. A pipe is created and the commands on the left (#part3) and right (#part2) are executed. exit $xs is also the last command of the pipe and that means the string from stdin will be the exit status of the entire construct.
3. A subshell is created with file descriptor 3 redirected to stdout. This means that whatever is printed to file descriptor 3 in this subshell will end up in #part2 and in turn will be the exit status of the entire construct.
4. A pipe is created and the commands on the left (#part5 and #part6) and right (filter >&4) are executed. The output of filter is redirected to file descriptor 4. In #part1 the file descriptor 4 was redirected to stdout. This means that the output of filter is the stdout of the entire construct.
5. Exit status from #part6 is printed to file descriptor 3. In #part3 file descriptor 3 was redirected to #part2. This means that the exit status from #part6 will be the final exit status for the entire construct.
6. someprog is executed. The exit status is taken in #part5. The stdout is taken by the pipe in #part4 and forwarded to filter. The output from filter will in turn reach stdout as explained in #part4

Answer 4

While not exactly what you asked, you could use

#!/bin/bash -o pipefail

so that your pipes return the last non zero return.

might be a bit less coding

Edit: Example

[root@localhost ~]# false | true
[root@localhost ~]# echo $?
0
[root@localhost ~]# set -o pipefail
[root@localhost ~]# false | true
[root@localhost ~]# echo $?
1

Answer 5

What I do when possible is to feed the exit code from foo into bar. For example, if I know that foo never produces a line with just digits, then I can just tack on the exit code:

{ foo; echo "$?"; } | awk '!/[^0-9]/ {exit($0)} {…}'

Or if I know that the output from foo never contains a line with just .:

{ foo; echo .; echo "$?"; } | awk '/^\.$/ {getline; exit($0)} {…}'

This can always be done if there's some way of getting bar to work on all but the last line, and pass on the last line as its exit code.

If bar is a complex pipeline whose output you don't need, you can bypass part of it by printing the exit code on a different file descriptor.

exit_codes=$({ { foo; echo foo:"$?" >&3; } |
               { bar >/dev/null; echo bar:"$?" >&3; }
             } 3>&1)

After this $exit_codes is usually foo:X bar:Y, but it could be bar:Y foo:X if bar quits before reading all of its input or if you're unlucky. I think writes to pipes of up to 512 bytes are atomic on all unices, so the foo:$? and bar:$? parts won't be intermixed as long as the tag strings are under 507 bytes.

If you need to capture the output from bar, it gets difficult. You can combine the techniques above by arranging for the output of bar never to contain a line that looks like an exit code indication, but it does get fiddly.

output=$(echo;
         { { foo; echo foo:"$?" >&3; } |
           { bar | sed 's/^/^/'; echo bar:"$?" >&3; }
         } 3>&1)
nl='
'
foo_exit_code=${output#*${nl}foo:}; foo_exit_code=${foo_exit_code%%$nl*}
bar_exit_code=${output#*${nl}bar:}; bar_exit_code=${bar_exit_code%%$nl*}
output=$(printf %s "$output" | sed -n 's/^\^//p')

And, of course, there's the simple option of using a temporary file to store the status. Simple, but not that simple in production:

• If there are multiple scripts running concurrently, or if the same script uses this method in several places, you need to make sure they use different temporary file names.
• Creating a temporary file securely in a shared directory is hard. Often, /tmp is the only place where a script is sure to be able to write files. Use mktemp, which is not POSIX but available on all serious unices nowadays.

foo_ret_file=$(mktemp -t)
{ foo; echo "$?" >"$foo_ret_file"; } | bar
bar_ret=$?
foo_ret=$(cat "$foo_ret_file"; rm -f "$foo_ret_file")

Answer 6

Starting from the pipeline:

foo | bar | baz

Here is a general solution using only POSIX shell and no temporary files:

exec 4>&1
error_statuses="`((foo || echo "0:$?" >&3) |
        (bar || echo "1:$?" >&3) | 
        (baz || echo "2:$?" >&3)) 3>&1 >&4`"
exec 4>&-

$error_statuses contains the status codes of any failed processes, in random order, with indexes to tell which command emitted each status.

# if "bar" failed, output its status:
echo "$error_statuses" | grep '1:' | cut -d: -f2

# test if all commands succeeded:
test -z "$error_statuses"

# test if the last command succeeded:
! echo "$error_statuses" | grep '2:' >/dev/null

Note the quotes around $error_statuses in my tests; without them grep can't differentiate because the newlines get coerced to spaces.

Answer 7

So I wanted to contribute an answer like lesmana's, but I think mine is perhaps a little simpler and slightly more advantageous pure-Bourne-shell solution:

# You want to pipe command1 through command2:
exec 4>&1
exitstatus=`{ { command1; printf $? 1>&3; } | command2 1>&4; } 3>&1`
# $exitstatus now has command1's exit status.

I think this is best explained from the inside out – command1 will execute and print its regular output on stdout (file descriptor 1), then once it's done, printf will execute and print command1's exit code on its stdout, but that stdout is redirected to file descriptor 3.

While command1 is running, its stdout is being piped to command2 (printf's output never makes it to command2 because we send it to file descriptor 3 instead of 1, which is what the pipe reads). Then we redirect command2's output to file descriptor 4, so that it also stays out of file descriptor 1 – because we want file descriptor 1 free for a little bit later, because we will bring the printf output on file descriptor 3 back down into file descriptor 1 – because that's what the command substitution (the backticks), will capture and that's what will get placed into the variable.

The final bit of magic is that first exec 4>&1 we did as a separate command – it opens file descriptor 4 as a copy of the external shell's stdout. Command substitution will capture whatever is written on standard out from the perspective of the commands inside it – but, since command2's output is going to file descriptor 4 as far as the command substitution is concerned, the command substitution doesn't capture it – however, once it gets "out" of the command substitution, it is effectively still going to the script's overall file descriptor 1.

(The exec 4>&1 has to be a separate command because many common shells don't like it when you try to write to a file descriptor inside a command substitution, that is opened in the "external" command that is using the substitution. So this is the simplest portable way to do it.)

You can look at it in a less technical and more playful way, as if the outputs of the commands are leapfrogging each other: command1 pipes to command2, then the printf's output jumps over command 2 so that command2 doesn't catch it, and then command 2's output jumps over and out of the command substitution just as printf lands just in time to get captured by the substitution so that it ends up in the variable, and command2's output goes on its merry way being written to the standard output, just as in a normal pipe.

Also, as I understand it, $? will still contain the return code of the second command in the pipe, because variable assignments, command substitutions, and compound commands are all effectively transparent to the return code of the command inside them, so the return status of command2 should get propagated out – this, and not having to define an additional function, is why I think this might be a somewhat better solution than the one proposed by lesmana.

Per the caveats lesmana mentions, it's possible that command1 will at some point end up using file descriptors 3 or 4, so to be more robust, you would do:

exec 4>&1
exitstatus=`{ { command1 3>&-; printf $? 1>&3; } 4>&- | command2 1>&4; } 3>&1`
exec 4>&-

Note that I use compound commands in my example, but subshells (using ( ) instead of { } will also work, though may perhaps be less efficient.)

Commands inherit file descriptors from the process that launches them, so the entire second line will inherit file descriptor four, and the compound command followed by 3>&1 will inherit the file descriptor three. So the 4>&- makes sure that the inner compound command will not inherit file descriptor four, and the 3>&- will not inherit file descriptor three, so command1 gets a 'cleaner', more standard environment. You could also move the inner 4>&- next to the 3>&-, but I figure why not just limit its scope as much as possible.

I'm not sure how often things use file descriptor three and four directly – I think most of the time programs use syscalls that return not-used-at-the-moment file descriptors, but sometimes code writes to file descriptor 3 directly, I guess (I could imagine a program checking a file descriptor to see if it's open, and using it if it is, or behaving differently accordingly if it's not). So the latter is probably best to keep in mind and use for general-purpose cases.

Answer 8

If you have the moreutils package installed you can use the mispipe utility which does exactly what you asked.

Answer 9

lesmana's solution above can also be done without the overhead of starting nested subprocesses by using { .. } instead (remembering that this form of grouped commands always has to finish with semicolons). Something like this:

{ { { { someprog; echo $? >&3; } | filter >&4; } 3>&1; } | stdintoexitstatus; } 4>&1

I've checked this construct with dash version 0.5.5 and bash versions 3.2.25 and 4.2.42, so even if some shells don't support { .. } grouping, it is still POSIX compliant.

Answer 10

This is portable, i.e. works with any POSIX compliant shell, doesn't require the current directory to be writable and allows multiple scripts using the same trick to run simultaneously.

(foo;echo $?>/tmp/_$$)|(bar;exit $(cat /tmp/_$$;rm /tmp/_$$))

Edit: here is a stronger version following Gilles' comments:

(s=/tmp/.$$_$RANDOM;((foo;echo $?>$s)|(bar)); exit $(cat $s;rm $s))

Edit2: and here is a slightly lighter variant following dubiousjim comment:

(s=/tmp/.$$_$RANDOM;{foo;echo $?>$s;}|bar; exit $(cat $s;rm $s))

Answer 11

Following is meant as an addon to the answer of @Patrik, in case you are not able to use one of the common solutions.

This answer assumes following:

• You have a shell which does not know of $PIPESTATUS nor set -o pipefail
• You want to use a pipe for parallel execution, so no temporary files.
• You do not want to have additional clutter around if you interrupt the script, possibly by a sudden power outage.
• This solution should be relatively easy to follow and clean to read.
• You do not want to introduce additional subshells.
• You cannot fiddle with the existing file descriptors, so stdin/out/err must not be touched (however you can introduce some new one temporarily)

Additional assumptions. You can get rid of all, but this clobbers the recipe too much, so it is not covered here:

• All you want to know is that all commands in the PIPE have exit code 0.
• You do not need additional side band information.
• Your shell does wait for all pipe commands to return.

Before: foo | bar | baz, however this only returns the exit code of the last command (baz)

Wanted: $? must not be 0 (true), if any of the commands in the pipe failed

After:

TMPRESULTS="`mktemp`"
{
rm -f "$TMPRESULTS"

{ foo || echo $? >&9; } |
{ bar || echo $? >&9; } |
{ baz || echo $? >&9; }
#wait
! read TMPRESULTS <&8
} 9>>"$TMPRESULTS" 8<"$TMPRESULTS"

# $? now is 0 only if all commands had exit code 0

Explained:

• A tempfile is created with mktemp. This usually immediately creates a file in /tmp
• This tempfile is then redirected to FD 9 for write and FD 8 for read
• Then the tempfile is immediately deleted. It stays open, though, until both FDs go out of existence.
• Now the pipe is started. Each step adds to FD 9 only, if there was an error.
• The wait is needed for ksh, because ksh else does not wait for all pipe commands to finish. However please note that there are unwanted sideffects if some background tasks are present, so I commented it out by default. If the wait does not hurt, you can comment it in.
• Afterwards the file's contents are read. If it is empty (because all worked) read returns false, so true indicates an error

This can be used as a plugin replacement for a single command and only needs following:

• Unused FDs 9 and 8
• A single environment variable to hold the name of the tempfile
• And this recipe can be adapted to fairly any shell out there which allows IO redirection
• Also it is fairly platform agnostic and does not need things like /proc/fd/N

BUGs:

This script has a bug in case /tmp runs out of space. If you need protection against this artificial case, too, you can do it as follows, however this has the disadvantage, that the number of 0 in 000 depends on the number of commands in the pipe, so it is slightly more complicated:

TMPRESULTS="`mktemp`"
{
rm -f "$TMPRESULTS"

{ foo; printf "%1s" "$?" >&9; } |
{ bar; printf "%1s" "$?" >&9; } |
{ baz; printf "%1s" "$?" >&9; }
#wait
read TMPRESULTS <&8
[ 000 = "$TMPRESULTS" ]
} 9>>"$TMPRESULTS" 8<"$TMPRESULTS"

Portablility notes:

• ksh and similar shells which only wait for the last pipe command need the wait uncommented

• The last example uses printf "%1s" "$?" instead of echo -n "$?" because this is more portable. Not every platform interprets -n correctly.

• printf "$?" would do it as well, however printf "%1s" catches some corner cases in case you run the script on some really broken platform. (Read: if you happen to program in paranoia_mode=extreme.)

• FD 8 and FD 9 can be higher on platforms which support multiple digits. AFAIR a POSIX conformant shell does only need to support single digits.

• Was tested with Debian 8.2 sh, bash, ksh, ash, sash and even csh

Answer 12

With a bit of precaution, this should work:

foo-status=$(mktemp -t)
(foo; echo $? >$foo-status) | bar
foo_status=$(cat $foo-status)

Answer 13

The following 'if' block will run only if 'command' succeeded:

if command; then
   # ...
fi

Specifically speaking, you can run something like this:

haconf_out=/path/to/some/temporary/file

if haconf -makerw > "$haconf_out" 2>&1; then
   grep -iq "Cluster already writable" "$haconf_out"
   # ...
fi

Which will run haconf -makerw and store its stdout and stderr to "$haconf_out". If the returned value from haconf is true, then the 'if' block will be executed and grep will read "$haconf_out", trying to match it against "Cluster already writable".

Notice that pipes automatically clean themselves up; with the redirection you'll have to be carefull to remove "$haconf_out" when done.

Not as elegant as pipefail, but a legitimate alternative if this functionality is not within reach.

Answer 14

Alternate example for @lesmana solution, possibly simplified.
Provides logging to file if desired.
=====
$ cat z.sh
TEE="cat"
#TEE="tee z.log"
#TEE="tee -a z.log"

exec 8>&- 9>&-
{
  {
    {
      { #BEGIN - add code below this line and before #END
./zz.sh
echo ${?} 1>&8  # use exactly 1x prior to #END
      #END
      } 2>&1 | ${TEE} 1>&9
    } 8>&1
  } | exit $(read; printf "${REPLY}")
} 9>&1

exit ${?}
$ cat zz.sh
echo "my script code..."
exit 42
$ ./z.sh; echo "status=${?}"
my script code...
status=42
$

Answer 15

For everyone using bash. I think that by far cleanest solution to both get output value and each exit status in pipe is this.

1. A one-time preparation. Enable lastpipe shell option. It allows to get value from the last command in pipe without using subshell. If you're in an interactive shell, also disable job control: set +m (The latter isn't needed for scripts - job control is disabled there by default.)

   shopt -s lastpipe
   set +m
   

2. read the value into your variable, and use PIPESTATUS naturally. E.g.

   grep -E "\S" "file.txt" | sort | uniq | read -d '' RES
   # 'read' exit status 1 means all input was read till EOF, we're OK with that
   if (( PIPESTATUS[0] > 1 || PIPESTATUS[1] > 0 || PIPESTATUS[2] > 0 || PIPESTATUS[3] > 1 )); then
     echo "ERROR"
   else
     echo "$RES"
   fi
   

The above reads all non-empty lines from "file.txt", sorts them and removes duplicates. In this example we have custom processing of exit codes: grep exit status 1 means no lines were selected, we're OK with that; read exit status 1 is expected for saving multi-line output (at least, I don't know another clean way to do it). Clean means without cluttering the code just to avoid the exit status of 1 of read.

NOTE: the read -d '' option is used to read all the input into our variable (by disabling delimiter read stops at, which by default is a newline symbol). This is how we save multi-line output. If your pipe has just one line then you can use plain read RES (and likely can change expected exit status from read to 0 and not 1 as above).

Answer 16

(With bash at least) combined with set -e one can use subshell to explicitly emulate pipefail and exit on pipe error

set -e
foo | bar
( exit ${PIPESTATUS[0]} )
rest of program

So if foo fails for some reason - the rest of program will not be executed and script exits with corresponding error code. (This assumes that foo prints its own error, which is sufficient to understand the reason of failure)

Answer 17

The following answer is similar to some other ones (especially [0] and [1] ) here, with the difference:

• It also captures (in a variable) the standard output of the final program in the pipeline.

It also:

• tries to be POSIX compatible
• retrieves the exit status of the commands in the pipeline
• lets standard error (file descriptor 2) pass through

Extensions and limitations:

• I guess it should be extensible to have more than one command in the pipeline.
• But it can return only one of the exit statuses (or a combined one).

As you'll see from my choice of commands (one that reads binary data and base64), I've used this to read and store binary data (including 0x0) in a Shell variable (of course in encoded form only). If that needs to be processed later it would need to be decoded again (e.g. printf '%s' "${stdout_command2}" | base64 -d | someting_that_can_handle_binary_data).

This is the construct:

stdout_command2="$(
                    exec 4>&1
                    exitstatus_command1="$(
                                            {
                                                { read_binary 3>&- ; printf $? >&3 ; } 4>&-   | \
                                                base64 -w 0 >&4 3>&- 4>&- ;
                                            } 3>&1
                                        )" 4>&1
                    exitstatus_command2=$?  # this must come directly after the above command substitution
                    exec 4>&-
                if [ "${exitstatus_command1}" -ne 0 ]; then
                    exit 11
                fi
                if [ "${exitstatus_command2}" -ne 0 ]; then
                    exit 22
                fi
            )"


overall_exitstatus=$?   # this would be e.g. 11 or 22 if either of the two commands failed

This seems to work in dash, bash and busybox’s sh respectively ash.

The exec 4>&1 (and subsequent closure with exec 4>&-) is needed in order to be POSIX-ly correct:
For a simple command with no command word (which there is none in the exitstatus_command1=… line, which is just an assignment), POSIX leaves the order of variable assignments and redirections open (see 2.9.1 Simple Commands: “In the preceding list, the order of steps 3 and 4 may be reversed if no command name results from step 2…”).
For example dash and busybox’s sh respectively ash seem to perform the redirection before the assignment (which thus works without the exec), while bash performs it afterwards (which thus fails without the exec).

I also close file descriptors 3 and 4 where these are not needed:

• 3, with 3>&- for read_binary
• 4, with 4>&- for the whole { read_binary 3>&- ; printf $? >&3 ; }
• 3 and 4, with 3>&- 4>&- for base64 -w 0 but only after 1 has been redirected to 4 with >&4 (so order matters)

You can check which file descriptors are seen by the commands, by wrapping them in extra shell scripts like this:

#!/bin/sh
find /proc/$$/fd -type l | sort -V |  sed 's/^/before /' >&2
base64 -w 0
e=$?
find /proc/$$/fd -type l | sort -V |  sed 's/^/after /' >&2
exit $e

I for some reasons (which I didn’t quite understand) it did not work by wrapping them in shell functions executed in the same shell as the construct above. In that case I never so all the extra file descriptors.

Last but not least, e.g. read_binary (or base64) could very well be functions (executed in the same shell), like so:

read_binary()
{
    if [ -z "${foo}" ]
        some_more_complext_read"${path}"
        if [ $? -ne 0 ]; then
            return 1
            #exit 1 # exit wouldn't work here
        fi
    else
        cat -- "${path}"
        if [ $? -ne 0 ]; then
            return 1
            #exit 2 # exit wouldn't work here
        fi
    fi
}

But beware that one cannot use exit in such function (with the above construct), as that would not just leave the function, but the whole subshell from the respective command subsitution ($(…)).

And exit in either read_binary or base64 (if that was a function) might cause the printf $? >&3 to never happen and thus that exit status would get lost.

Answer 18

If you aren't interested in making use of the actual value in the script, per se, but instead dealing with the errors on each element in a pipeline, you can do something like:

    if ! command1
    then
        error_handler1
    fi | \
    if ! command2
    then
        error_handler2
    fi | \
    if ! command3
    then
        error_handler3
    fi | \
...

Answer 19

This is what "mispipe" (included in moreutils https://joeyh.name/code/moreutils/ ) was written for.

mispipe "prog1 | prog2 | prog3" "prog4 | prog 5"

will run like

prog1 | prog2 | prog3 | prog4 | prog5

except that it will return the exit status at the end of prog3, and will completely ignore the exit status of the later programs in the pipe.

This is ideal for certain logging situations where you don't care whether the logger programs at the end of the pipe (prog4 | prog5) fail, but you do care very much whether the main programs in the pipe (prog1 | prog2 | prog3) fail.

Internally, the mispipe program is very straightforwardly written in C.

It uses "system()" to execute its two arguments (after linking the standard output and input together properly with pipes and making sure signals will be handled right). So it will execute the subcommands with whatever the standard system shell is, which should be fine if you're writing in portable Bourne shell.

Answer 20

As yet another approach, you can use fifo inode files and explicit job control. They make the script much more verbose, but allow for finer control over the execution. Fifo inodes have an advantage over straight files, because they don't consume disk space. This can matter if you're running in a limited environment or have a script working with large files.

It does imply, though, that your execution environment must support fifo inodes and your shell must support basic job control.

Rather than, say:

generate-large-data | sort | uniq

You can use:

#!/bin/sh
Put the fifo files in a secure, temporary directory.
fifos="$( mktemp -d )" || exit 1
And clean up when complete.
trap 'rm -r "${fifos}"' EXIT
Create the fifo queues
mkfifo "${fifos}/gen.fifo" || exit 1
mkfifo "${fifos}/sort.fifo" || exit 1
Pipe the generate-large-data output into the gen fifo file
generate-large-data > "${fifos}/gen.fifo" &
and capture the job id.
gen_job=%%
The sort operation reads from the generated data fifo and outputs to its own.
sort < "${fifos}/gen.fifo" > "${fifos}/sort.fifo" &
and capture the job id.
sort_job=%%
Uniq, as the final operation, runs as a usual command, not as a job.
uniq < "${fifos}/sort.fifo"
uniq_code=$?
Now, the script can capture the exit code for each job in the pipeline.
"wait" waits for the job to end, and exits with the job's exit code.
wait ${gen_job}
gen_code=$?
wait ${sort_job}
sort_code=$?
And the script can access each exit code.
echo "generate-large-data exit code: ${gen_code}"
echo "sort exit code: ${sort_code}"
echo "uniq exit code: ${uniq_code}"

Unlike some other approaches, this gives your script complete access to all exit codes in every step of the operation.

Answer 21

EDIT: This answer is wrong, but interesting, so I'll leave it for future reference.

---

Adding a ! to the command inverts the return code.

http://tldp.org/LDP/abs/html/exit-status.html

# =========================================================== #
# Preceding a _pipe_ with ! inverts the exit status returned.
ls | bogus_command     # bash: bogus_command: command not found
echo $?                # 127

! ls | bogus_command   # bash: bogus_command: command not found
echo $?                # 0
# Note that the ! does not change the execution of the pipe.
# Only the exit status changes.
# =========================================================== #