Scott,
Generally I run pg_dump nohup in the background with all outputs captured to a file. Finding the exit message is simply a matter of navigating to the bottom of the output file and checking.
Excepting for pg_dump, I don't generally have to worry about exit values as most command line programs are either short-lived and obvious, like ls, or emit their own text exit status.
In my experience checking exit status codes are what you do when writing programs to determine the status of a subroutine or function that you are calling. Stand alone programs that are expected to take any appreciable amount of time to run generally provide an status output, precisely for this reason.
I hope that the devs reconsider and add a status output message. If checking the exit status is the only way to determine if the pg_dump process completed successfully, then I am going to be forced to create a wrapper to capture and emit the status around the pg_dump executable. If I need to do that, so will every other user who needs to know the exit status and runs pg_dump in a typical linux workflow. Seems like a terrible waste having untold numbers of users having to constantly reinvent the wheel.
rik.
On Mon, May 1, 2023 at 9:07 AM Scott Ribe <scott_ribe@xxxxxxxxxxxxxxxx> wrote:
> On May 1, 2023, at 7:01 AM, richard coleman <rcoleman.ascentgl@xxxxxxxxx> wrote:
>
> Which, running more than one command from the shell prompt in a single logon session, or not emitting an exit message?
Running multiple long-lived processes in a shell prompt, whose exit values you care about, running in the background, along with "a myriad of other commands", presumably short-lived, in the interim, then looking through "the flotsam and jetsam" for a success message. Sounds like a total mess. Put your important long-lived processesin their own sessions. Or, if you must interleave them, wrap the call to pg_dump in a simple conditional.
