Is there a way to get an process exit status after many more commands have been issued in linux?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
7
down vote

favorite
2












If I have a lot of commands I've issued and I want the exit status of a process that exited say 100 commands ago. Is there a struct, file location, or variable in linux I can access all of exited processes and see information about them?










share|improve this question

























    up vote
    7
    down vote

    favorite
    2












    If I have a lot of commands I've issued and I want the exit status of a process that exited say 100 commands ago. Is there a struct, file location, or variable in linux I can access all of exited processes and see information about them?










    share|improve this question























      up vote
      7
      down vote

      favorite
      2









      up vote
      7
      down vote

      favorite
      2






      2





      If I have a lot of commands I've issued and I want the exit status of a process that exited say 100 commands ago. Is there a struct, file location, or variable in linux I can access all of exited processes and see information about them?










      share|improve this question













      If I have a lot of commands I've issued and I want the exit status of a process that exited say 100 commands ago. Is there a struct, file location, or variable in linux I can access all of exited processes and see information about them?







      linux linux-kernel exit-code






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Sep 19 at 18:51









      mutant_city

      1411




      1411




















          3 Answers
          3






          active

          oldest

          votes

















          up vote
          3
          down vote













          If BSD process accounting was enabled (accton on was issued), with GNU acct 6.6.3 or above, you can get that information from lastcomm --debug or dump-acct /var/log/account/pact (or wherever the process accounting data is stored on your system).




          $ perl -e 'exit 123'
          $ lastcomm --debug | grep perl
          CURRENT REC: perl |v3| 0.00| 0.00| 0.00| 1000| 1000| 26328.00| 0.00| 332| 8530| | 123|pts/1 |Wed Sep 19 20:21:26 2018
          $ dump-acct /var/log/account/pacct | grep perl
          perl |v3| 0.00| 0.00| 0.00| 1000| 1000| 26328.00| 0.00| 332| 8530| | 123|pts/1 |Wed Sep 19 20:21:26 2018


          You get the exit code in the 3rd last field and whether it was killed or not (but not the signal number, see @mosvy's answer for that) in the 4th last one.






          share|improve this answer





























            up vote
            2
            down vote













            If you're on debian, you can install the acct package in order to enable process accounting, but notice that neither lastcomm --debug nor dump-acct show anything like the exit status or the signal that terminated a process.



            If order to get that data, you can use a script like this:



            $ cat pacct.pl
            #! /usr/bin/perl
            use strict;
            use Config;
            printf "%-7s %6s %6s %8s %8s %sn",
            'STATUS', 'UID', 'PID', 'BTIME', 'ETIME', 'COMMAND';
            my @sig = split ' ', $Configsig_name;
            $/ = 64;
            while(<>)
            my @f = unpack 'CCSL6fS8A*', $_;
            my ($flag, $version, $tty, $exitcode, $uid, $gid, $pid, $ppid,
            $btime, $etime, $utime, $stime, $mem, $io, $rw,
            $minflt, $majflt, $swaps, $cmd) = @f;
            my $s = $exitcode & 0x7f;
            my $status = $s ? "SIG$sig[$s]" : $exitcode >> 8;
            printf "%-7s %6d %6d %02d:%02d:%02d %8.2f %-16sn",
            $status, $uid, $pid,
            (localtime $btime)[2,1,0],
            $etime / 100,
            $cmd;

            $ perl pacct.pl /var/log/account/pacct


            This assumes the version 3 of the log file format -- see acct.h.



            Notice however that this isn't that useful, because only the process/thread name in included in the log file (ie the basename of the executable, truncated to 15 bytes, and which could be easily faked with prctl(PR_SET_NAME)), not the path of the executable or the arguments it was invoked with.



            If you want to extend that script to also display the stime, utime, etc fields, this may be useful:



            # translate comp_t to float
            # utime, stime, mem, minflt, majflt are in the comp_t format
            # io, rw, swaps are never set; they're purely decorative
            sub comp2f
            my $m = $_[0] & 0x1fff; my $e = $_[0] >> 13; $m * 8 ** $e;






            share|improve this answer






















            • What version of Debian did you try lastcomm --debug/dump-acct on? It worked for me on Debian unstable and on Ubuntu 18.04 (though doesn't give the signal number for those processes that were killed)
              – Stéphane Chazelas
              Sep 20 at 10:41











            • Note that it's not the command name, it's the process name (changed by each execve() call the process makes to the first 15 bytes of the basename of the executed file). You can't change it with overwriting argv[0], but with prctl(PR_SET_NAME, newname) or execve(). When you do env sh -c 'exec bash -c "exit 123"', that's one process that runs in turn env, sh and bash. The pacct log will show only one entry for bash (the name of the process at the time it exited)
              – Stéphane Chazelas
              Sep 20 at 11:01











            • @StéphaneChazelas stretch(stable)
              – mosvy
              Sep 20 at 11:16










            • Yes, you need GNU acct 6.6.3 or above. stretch has 6.6.2.
              – Stéphane Chazelas
              Sep 20 at 12:20

















            up vote
            -1
            down vote













            The



             set -o pipefail 


            is pretty close to what you want; it will




            A pipeline will not complete until all components of the pipeline have
            completed, and the return value will be the value of the last non-zero command
            to fail or zero if no command has failed.




            So if you have 40 commands piped together, and the third command gives a return code of 8, and the rest complete successfully, then the overall return code would be 8. To figure out which command gave the bad return code would be tricky.






            share|improve this answer
















            • 1




              There is no indication that the commands are issued as part of the same pipeline.
              – Kusalananda
              Sep 19 at 19:18










            • Good point; I didn't read the question closely enough, but I'll leave the answer just in case someone may benefit from it. It was one of my nice surprises I found when moving from Solaris to Linux.
              – Mark Stewart
              Sep 19 at 20:04






            • 1




              Yeah thanks. There's a PIPESTATUS[0] environmental variable as well for pipelines. This would be just in general.
              – mutant_city
              Sep 21 at 1:44










            Your Answer







            StackExchange.ready(function()
            var channelOptions =
            tags: "".split(" "),
            id: "106"
            ;
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function()
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled)
            StackExchange.using("snippets", function()
            createEditor();
            );

            else
            createEditor();

            );

            function createEditor()
            StackExchange.prepareEditor(
            heartbeatType: 'answer',
            convertImagesToLinks: false,
            noModals: false,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: null,
            bindNavPrevention: true,
            postfix: "",
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            );



            );













             

            draft saved


            draft discarded


















            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f470103%2fis-there-a-way-to-get-an-process-exit-status-after-many-more-commands-have-been%23new-answer', 'question_page');

            );

            Post as a guest






























            3 Answers
            3






            active

            oldest

            votes








            3 Answers
            3






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes








            up vote
            3
            down vote













            If BSD process accounting was enabled (accton on was issued), with GNU acct 6.6.3 or above, you can get that information from lastcomm --debug or dump-acct /var/log/account/pact (or wherever the process accounting data is stored on your system).




            $ perl -e 'exit 123'
            $ lastcomm --debug | grep perl
            CURRENT REC: perl |v3| 0.00| 0.00| 0.00| 1000| 1000| 26328.00| 0.00| 332| 8530| | 123|pts/1 |Wed Sep 19 20:21:26 2018
            $ dump-acct /var/log/account/pacct | grep perl
            perl |v3| 0.00| 0.00| 0.00| 1000| 1000| 26328.00| 0.00| 332| 8530| | 123|pts/1 |Wed Sep 19 20:21:26 2018


            You get the exit code in the 3rd last field and whether it was killed or not (but not the signal number, see @mosvy's answer for that) in the 4th last one.






            share|improve this answer


























              up vote
              3
              down vote













              If BSD process accounting was enabled (accton on was issued), with GNU acct 6.6.3 or above, you can get that information from lastcomm --debug or dump-acct /var/log/account/pact (or wherever the process accounting data is stored on your system).




              $ perl -e 'exit 123'
              $ lastcomm --debug | grep perl
              CURRENT REC: perl |v3| 0.00| 0.00| 0.00| 1000| 1000| 26328.00| 0.00| 332| 8530| | 123|pts/1 |Wed Sep 19 20:21:26 2018
              $ dump-acct /var/log/account/pacct | grep perl
              perl |v3| 0.00| 0.00| 0.00| 1000| 1000| 26328.00| 0.00| 332| 8530| | 123|pts/1 |Wed Sep 19 20:21:26 2018


              You get the exit code in the 3rd last field and whether it was killed or not (but not the signal number, see @mosvy's answer for that) in the 4th last one.






              share|improve this answer
























                up vote
                3
                down vote










                up vote
                3
                down vote









                If BSD process accounting was enabled (accton on was issued), with GNU acct 6.6.3 or above, you can get that information from lastcomm --debug or dump-acct /var/log/account/pact (or wherever the process accounting data is stored on your system).




                $ perl -e 'exit 123'
                $ lastcomm --debug | grep perl
                CURRENT REC: perl |v3| 0.00| 0.00| 0.00| 1000| 1000| 26328.00| 0.00| 332| 8530| | 123|pts/1 |Wed Sep 19 20:21:26 2018
                $ dump-acct /var/log/account/pacct | grep perl
                perl |v3| 0.00| 0.00| 0.00| 1000| 1000| 26328.00| 0.00| 332| 8530| | 123|pts/1 |Wed Sep 19 20:21:26 2018


                You get the exit code in the 3rd last field and whether it was killed or not (but not the signal number, see @mosvy's answer for that) in the 4th last one.






                share|improve this answer














                If BSD process accounting was enabled (accton on was issued), with GNU acct 6.6.3 or above, you can get that information from lastcomm --debug or dump-acct /var/log/account/pact (or wherever the process accounting data is stored on your system).




                $ perl -e 'exit 123'
                $ lastcomm --debug | grep perl
                CURRENT REC: perl |v3| 0.00| 0.00| 0.00| 1000| 1000| 26328.00| 0.00| 332| 8530| | 123|pts/1 |Wed Sep 19 20:21:26 2018
                $ dump-acct /var/log/account/pacct | grep perl
                perl |v3| 0.00| 0.00| 0.00| 1000| 1000| 26328.00| 0.00| 332| 8530| | 123|pts/1 |Wed Sep 19 20:21:26 2018


                You get the exit code in the 3rd last field and whether it was killed or not (but not the signal number, see @mosvy's answer for that) in the 4th last one.







                share|improve this answer














                share|improve this answer



                share|improve this answer








                edited Sep 20 at 12:19

























                answered Sep 19 at 19:23









                Stéphane Chazelas

                287k53528867




                287k53528867






















                    up vote
                    2
                    down vote













                    If you're on debian, you can install the acct package in order to enable process accounting, but notice that neither lastcomm --debug nor dump-acct show anything like the exit status or the signal that terminated a process.



                    If order to get that data, you can use a script like this:



                    $ cat pacct.pl
                    #! /usr/bin/perl
                    use strict;
                    use Config;
                    printf "%-7s %6s %6s %8s %8s %sn",
                    'STATUS', 'UID', 'PID', 'BTIME', 'ETIME', 'COMMAND';
                    my @sig = split ' ', $Configsig_name;
                    $/ = 64;
                    while(<>)
                    my @f = unpack 'CCSL6fS8A*', $_;
                    my ($flag, $version, $tty, $exitcode, $uid, $gid, $pid, $ppid,
                    $btime, $etime, $utime, $stime, $mem, $io, $rw,
                    $minflt, $majflt, $swaps, $cmd) = @f;
                    my $s = $exitcode & 0x7f;
                    my $status = $s ? "SIG$sig[$s]" : $exitcode >> 8;
                    printf "%-7s %6d %6d %02d:%02d:%02d %8.2f %-16sn",
                    $status, $uid, $pid,
                    (localtime $btime)[2,1,0],
                    $etime / 100,
                    $cmd;

                    $ perl pacct.pl /var/log/account/pacct


                    This assumes the version 3 of the log file format -- see acct.h.



                    Notice however that this isn't that useful, because only the process/thread name in included in the log file (ie the basename of the executable, truncated to 15 bytes, and which could be easily faked with prctl(PR_SET_NAME)), not the path of the executable or the arguments it was invoked with.



                    If you want to extend that script to also display the stime, utime, etc fields, this may be useful:



                    # translate comp_t to float
                    # utime, stime, mem, minflt, majflt are in the comp_t format
                    # io, rw, swaps are never set; they're purely decorative
                    sub comp2f
                    my $m = $_[0] & 0x1fff; my $e = $_[0] >> 13; $m * 8 ** $e;






                    share|improve this answer






















                    • What version of Debian did you try lastcomm --debug/dump-acct on? It worked for me on Debian unstable and on Ubuntu 18.04 (though doesn't give the signal number for those processes that were killed)
                      – Stéphane Chazelas
                      Sep 20 at 10:41











                    • Note that it's not the command name, it's the process name (changed by each execve() call the process makes to the first 15 bytes of the basename of the executed file). You can't change it with overwriting argv[0], but with prctl(PR_SET_NAME, newname) or execve(). When you do env sh -c 'exec bash -c "exit 123"', that's one process that runs in turn env, sh and bash. The pacct log will show only one entry for bash (the name of the process at the time it exited)
                      – Stéphane Chazelas
                      Sep 20 at 11:01











                    • @StéphaneChazelas stretch(stable)
                      – mosvy
                      Sep 20 at 11:16










                    • Yes, you need GNU acct 6.6.3 or above. stretch has 6.6.2.
                      – Stéphane Chazelas
                      Sep 20 at 12:20














                    up vote
                    2
                    down vote













                    If you're on debian, you can install the acct package in order to enable process accounting, but notice that neither lastcomm --debug nor dump-acct show anything like the exit status or the signal that terminated a process.



                    If order to get that data, you can use a script like this:



                    $ cat pacct.pl
                    #! /usr/bin/perl
                    use strict;
                    use Config;
                    printf "%-7s %6s %6s %8s %8s %sn",
                    'STATUS', 'UID', 'PID', 'BTIME', 'ETIME', 'COMMAND';
                    my @sig = split ' ', $Configsig_name;
                    $/ = 64;
                    while(<>)
                    my @f = unpack 'CCSL6fS8A*', $_;
                    my ($flag, $version, $tty, $exitcode, $uid, $gid, $pid, $ppid,
                    $btime, $etime, $utime, $stime, $mem, $io, $rw,
                    $minflt, $majflt, $swaps, $cmd) = @f;
                    my $s = $exitcode & 0x7f;
                    my $status = $s ? "SIG$sig[$s]" : $exitcode >> 8;
                    printf "%-7s %6d %6d %02d:%02d:%02d %8.2f %-16sn",
                    $status, $uid, $pid,
                    (localtime $btime)[2,1,0],
                    $etime / 100,
                    $cmd;

                    $ perl pacct.pl /var/log/account/pacct


                    This assumes the version 3 of the log file format -- see acct.h.



                    Notice however that this isn't that useful, because only the process/thread name in included in the log file (ie the basename of the executable, truncated to 15 bytes, and which could be easily faked with prctl(PR_SET_NAME)), not the path of the executable or the arguments it was invoked with.



                    If you want to extend that script to also display the stime, utime, etc fields, this may be useful:



                    # translate comp_t to float
                    # utime, stime, mem, minflt, majflt are in the comp_t format
                    # io, rw, swaps are never set; they're purely decorative
                    sub comp2f
                    my $m = $_[0] & 0x1fff; my $e = $_[0] >> 13; $m * 8 ** $e;






                    share|improve this answer






















                    • What version of Debian did you try lastcomm --debug/dump-acct on? It worked for me on Debian unstable and on Ubuntu 18.04 (though doesn't give the signal number for those processes that were killed)
                      – Stéphane Chazelas
                      Sep 20 at 10:41











                    • Note that it's not the command name, it's the process name (changed by each execve() call the process makes to the first 15 bytes of the basename of the executed file). You can't change it with overwriting argv[0], but with prctl(PR_SET_NAME, newname) or execve(). When you do env sh -c 'exec bash -c "exit 123"', that's one process that runs in turn env, sh and bash. The pacct log will show only one entry for bash (the name of the process at the time it exited)
                      – Stéphane Chazelas
                      Sep 20 at 11:01











                    • @StéphaneChazelas stretch(stable)
                      – mosvy
                      Sep 20 at 11:16










                    • Yes, you need GNU acct 6.6.3 or above. stretch has 6.6.2.
                      – Stéphane Chazelas
                      Sep 20 at 12:20












                    up vote
                    2
                    down vote










                    up vote
                    2
                    down vote









                    If you're on debian, you can install the acct package in order to enable process accounting, but notice that neither lastcomm --debug nor dump-acct show anything like the exit status or the signal that terminated a process.



                    If order to get that data, you can use a script like this:



                    $ cat pacct.pl
                    #! /usr/bin/perl
                    use strict;
                    use Config;
                    printf "%-7s %6s %6s %8s %8s %sn",
                    'STATUS', 'UID', 'PID', 'BTIME', 'ETIME', 'COMMAND';
                    my @sig = split ' ', $Configsig_name;
                    $/ = 64;
                    while(<>)
                    my @f = unpack 'CCSL6fS8A*', $_;
                    my ($flag, $version, $tty, $exitcode, $uid, $gid, $pid, $ppid,
                    $btime, $etime, $utime, $stime, $mem, $io, $rw,
                    $minflt, $majflt, $swaps, $cmd) = @f;
                    my $s = $exitcode & 0x7f;
                    my $status = $s ? "SIG$sig[$s]" : $exitcode >> 8;
                    printf "%-7s %6d %6d %02d:%02d:%02d %8.2f %-16sn",
                    $status, $uid, $pid,
                    (localtime $btime)[2,1,0],
                    $etime / 100,
                    $cmd;

                    $ perl pacct.pl /var/log/account/pacct


                    This assumes the version 3 of the log file format -- see acct.h.



                    Notice however that this isn't that useful, because only the process/thread name in included in the log file (ie the basename of the executable, truncated to 15 bytes, and which could be easily faked with prctl(PR_SET_NAME)), not the path of the executable or the arguments it was invoked with.



                    If you want to extend that script to also display the stime, utime, etc fields, this may be useful:



                    # translate comp_t to float
                    # utime, stime, mem, minflt, majflt are in the comp_t format
                    # io, rw, swaps are never set; they're purely decorative
                    sub comp2f
                    my $m = $_[0] & 0x1fff; my $e = $_[0] >> 13; $m * 8 ** $e;






                    share|improve this answer














                    If you're on debian, you can install the acct package in order to enable process accounting, but notice that neither lastcomm --debug nor dump-acct show anything like the exit status or the signal that terminated a process.



                    If order to get that data, you can use a script like this:



                    $ cat pacct.pl
                    #! /usr/bin/perl
                    use strict;
                    use Config;
                    printf "%-7s %6s %6s %8s %8s %sn",
                    'STATUS', 'UID', 'PID', 'BTIME', 'ETIME', 'COMMAND';
                    my @sig = split ' ', $Configsig_name;
                    $/ = 64;
                    while(<>)
                    my @f = unpack 'CCSL6fS8A*', $_;
                    my ($flag, $version, $tty, $exitcode, $uid, $gid, $pid, $ppid,
                    $btime, $etime, $utime, $stime, $mem, $io, $rw,
                    $minflt, $majflt, $swaps, $cmd) = @f;
                    my $s = $exitcode & 0x7f;
                    my $status = $s ? "SIG$sig[$s]" : $exitcode >> 8;
                    printf "%-7s %6d %6d %02d:%02d:%02d %8.2f %-16sn",
                    $status, $uid, $pid,
                    (localtime $btime)[2,1,0],
                    $etime / 100,
                    $cmd;

                    $ perl pacct.pl /var/log/account/pacct


                    This assumes the version 3 of the log file format -- see acct.h.



                    Notice however that this isn't that useful, because only the process/thread name in included in the log file (ie the basename of the executable, truncated to 15 bytes, and which could be easily faked with prctl(PR_SET_NAME)), not the path of the executable or the arguments it was invoked with.



                    If you want to extend that script to also display the stime, utime, etc fields, this may be useful:



                    # translate comp_t to float
                    # utime, stime, mem, minflt, majflt are in the comp_t format
                    # io, rw, swaps are never set; they're purely decorative
                    sub comp2f
                    my $m = $_[0] & 0x1fff; my $e = $_[0] >> 13; $m * 8 ** $e;







                    share|improve this answer














                    share|improve this answer



                    share|improve this answer








                    edited Sep 25 at 17:49

























                    answered Sep 19 at 23:40









                    mosvy

                    1,68719




                    1,68719











                    • What version of Debian did you try lastcomm --debug/dump-acct on? It worked for me on Debian unstable and on Ubuntu 18.04 (though doesn't give the signal number for those processes that were killed)
                      – Stéphane Chazelas
                      Sep 20 at 10:41











                    • Note that it's not the command name, it's the process name (changed by each execve() call the process makes to the first 15 bytes of the basename of the executed file). You can't change it with overwriting argv[0], but with prctl(PR_SET_NAME, newname) or execve(). When you do env sh -c 'exec bash -c "exit 123"', that's one process that runs in turn env, sh and bash. The pacct log will show only one entry for bash (the name of the process at the time it exited)
                      – Stéphane Chazelas
                      Sep 20 at 11:01











                    • @StéphaneChazelas stretch(stable)
                      – mosvy
                      Sep 20 at 11:16










                    • Yes, you need GNU acct 6.6.3 or above. stretch has 6.6.2.
                      – Stéphane Chazelas
                      Sep 20 at 12:20
















                    • What version of Debian did you try lastcomm --debug/dump-acct on? It worked for me on Debian unstable and on Ubuntu 18.04 (though doesn't give the signal number for those processes that were killed)
                      – Stéphane Chazelas
                      Sep 20 at 10:41











                    • Note that it's not the command name, it's the process name (changed by each execve() call the process makes to the first 15 bytes of the basename of the executed file). You can't change it with overwriting argv[0], but with prctl(PR_SET_NAME, newname) or execve(). When you do env sh -c 'exec bash -c "exit 123"', that's one process that runs in turn env, sh and bash. The pacct log will show only one entry for bash (the name of the process at the time it exited)
                      – Stéphane Chazelas
                      Sep 20 at 11:01











                    • @StéphaneChazelas stretch(stable)
                      – mosvy
                      Sep 20 at 11:16










                    • Yes, you need GNU acct 6.6.3 or above. stretch has 6.6.2.
                      – Stéphane Chazelas
                      Sep 20 at 12:20















                    What version of Debian did you try lastcomm --debug/dump-acct on? It worked for me on Debian unstable and on Ubuntu 18.04 (though doesn't give the signal number for those processes that were killed)
                    – Stéphane Chazelas
                    Sep 20 at 10:41





                    What version of Debian did you try lastcomm --debug/dump-acct on? It worked for me on Debian unstable and on Ubuntu 18.04 (though doesn't give the signal number for those processes that were killed)
                    – Stéphane Chazelas
                    Sep 20 at 10:41













                    Note that it's not the command name, it's the process name (changed by each execve() call the process makes to the first 15 bytes of the basename of the executed file). You can't change it with overwriting argv[0], but with prctl(PR_SET_NAME, newname) or execve(). When you do env sh -c 'exec bash -c "exit 123"', that's one process that runs in turn env, sh and bash. The pacct log will show only one entry for bash (the name of the process at the time it exited)
                    – Stéphane Chazelas
                    Sep 20 at 11:01





                    Note that it's not the command name, it's the process name (changed by each execve() call the process makes to the first 15 bytes of the basename of the executed file). You can't change it with overwriting argv[0], but with prctl(PR_SET_NAME, newname) or execve(). When you do env sh -c 'exec bash -c "exit 123"', that's one process that runs in turn env, sh and bash. The pacct log will show only one entry for bash (the name of the process at the time it exited)
                    – Stéphane Chazelas
                    Sep 20 at 11:01













                    @StéphaneChazelas stretch(stable)
                    – mosvy
                    Sep 20 at 11:16




                    @StéphaneChazelas stretch(stable)
                    – mosvy
                    Sep 20 at 11:16












                    Yes, you need GNU acct 6.6.3 or above. stretch has 6.6.2.
                    – Stéphane Chazelas
                    Sep 20 at 12:20




                    Yes, you need GNU acct 6.6.3 or above. stretch has 6.6.2.
                    – Stéphane Chazelas
                    Sep 20 at 12:20










                    up vote
                    -1
                    down vote













                    The



                     set -o pipefail 


                    is pretty close to what you want; it will




                    A pipeline will not complete until all components of the pipeline have
                    completed, and the return value will be the value of the last non-zero command
                    to fail or zero if no command has failed.




                    So if you have 40 commands piped together, and the third command gives a return code of 8, and the rest complete successfully, then the overall return code would be 8. To figure out which command gave the bad return code would be tricky.






                    share|improve this answer
















                    • 1




                      There is no indication that the commands are issued as part of the same pipeline.
                      – Kusalananda
                      Sep 19 at 19:18










                    • Good point; I didn't read the question closely enough, but I'll leave the answer just in case someone may benefit from it. It was one of my nice surprises I found when moving from Solaris to Linux.
                      – Mark Stewart
                      Sep 19 at 20:04






                    • 1




                      Yeah thanks. There's a PIPESTATUS[0] environmental variable as well for pipelines. This would be just in general.
                      – mutant_city
                      Sep 21 at 1:44














                    up vote
                    -1
                    down vote













                    The



                     set -o pipefail 


                    is pretty close to what you want; it will




                    A pipeline will not complete until all components of the pipeline have
                    completed, and the return value will be the value of the last non-zero command
                    to fail or zero if no command has failed.




                    So if you have 40 commands piped together, and the third command gives a return code of 8, and the rest complete successfully, then the overall return code would be 8. To figure out which command gave the bad return code would be tricky.






                    share|improve this answer
















                    • 1




                      There is no indication that the commands are issued as part of the same pipeline.
                      – Kusalananda
                      Sep 19 at 19:18










                    • Good point; I didn't read the question closely enough, but I'll leave the answer just in case someone may benefit from it. It was one of my nice surprises I found when moving from Solaris to Linux.
                      – Mark Stewart
                      Sep 19 at 20:04






                    • 1




                      Yeah thanks. There's a PIPESTATUS[0] environmental variable as well for pipelines. This would be just in general.
                      – mutant_city
                      Sep 21 at 1:44












                    up vote
                    -1
                    down vote










                    up vote
                    -1
                    down vote









                    The



                     set -o pipefail 


                    is pretty close to what you want; it will




                    A pipeline will not complete until all components of the pipeline have
                    completed, and the return value will be the value of the last non-zero command
                    to fail or zero if no command has failed.




                    So if you have 40 commands piped together, and the third command gives a return code of 8, and the rest complete successfully, then the overall return code would be 8. To figure out which command gave the bad return code would be tricky.






                    share|improve this answer












                    The



                     set -o pipefail 


                    is pretty close to what you want; it will




                    A pipeline will not complete until all components of the pipeline have
                    completed, and the return value will be the value of the last non-zero command
                    to fail or zero if no command has failed.




                    So if you have 40 commands piped together, and the third command gives a return code of 8, and the rest complete successfully, then the overall return code would be 8. To figure out which command gave the bad return code would be tricky.







                    share|improve this answer












                    share|improve this answer



                    share|improve this answer










                    answered Sep 19 at 19:06









                    Mark Stewart

                    5981415




                    5981415







                    • 1




                      There is no indication that the commands are issued as part of the same pipeline.
                      – Kusalananda
                      Sep 19 at 19:18










                    • Good point; I didn't read the question closely enough, but I'll leave the answer just in case someone may benefit from it. It was one of my nice surprises I found when moving from Solaris to Linux.
                      – Mark Stewart
                      Sep 19 at 20:04






                    • 1




                      Yeah thanks. There's a PIPESTATUS[0] environmental variable as well for pipelines. This would be just in general.
                      – mutant_city
                      Sep 21 at 1:44












                    • 1




                      There is no indication that the commands are issued as part of the same pipeline.
                      – Kusalananda
                      Sep 19 at 19:18










                    • Good point; I didn't read the question closely enough, but I'll leave the answer just in case someone may benefit from it. It was one of my nice surprises I found when moving from Solaris to Linux.
                      – Mark Stewart
                      Sep 19 at 20:04






                    • 1




                      Yeah thanks. There's a PIPESTATUS[0] environmental variable as well for pipelines. This would be just in general.
                      – mutant_city
                      Sep 21 at 1:44







                    1




                    1




                    There is no indication that the commands are issued as part of the same pipeline.
                    – Kusalananda
                    Sep 19 at 19:18




                    There is no indication that the commands are issued as part of the same pipeline.
                    – Kusalananda
                    Sep 19 at 19:18












                    Good point; I didn't read the question closely enough, but I'll leave the answer just in case someone may benefit from it. It was one of my nice surprises I found when moving from Solaris to Linux.
                    – Mark Stewart
                    Sep 19 at 20:04




                    Good point; I didn't read the question closely enough, but I'll leave the answer just in case someone may benefit from it. It was one of my nice surprises I found when moving from Solaris to Linux.
                    – Mark Stewart
                    Sep 19 at 20:04




                    1




                    1




                    Yeah thanks. There's a PIPESTATUS[0] environmental variable as well for pipelines. This would be just in general.
                    – mutant_city
                    Sep 21 at 1:44




                    Yeah thanks. There's a PIPESTATUS[0] environmental variable as well for pipelines. This would be just in general.
                    – mutant_city
                    Sep 21 at 1:44

















                     

                    draft saved


                    draft discarded















































                     


                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function ()
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f470103%2fis-there-a-way-to-get-an-process-exit-status-after-many-more-commands-have-been%23new-answer', 'question_page');

                    );

                    Post as a guest













































































                    Popular posts from this blog

                    How to check contact read email or not when send email to Individual?

                    Bahrain

                    Postfix configuration issue with fips on centos 7; mailgun relay