Re: Add SHELL_EXIT_CODE to psql

From: Justin Pryzby <pryzby(at)telsasoft(dot)com>
To: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
Cc: Maxim Orlov <orlovmg(at)gmail(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Add SHELL_EXIT_CODE to psql
Date: 2023-03-09 01:16:52
Message-ID: ZAkzhE9GpFzysdcJ@telsasoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Feb 22, 2023 at 03:04:33PM -0500, Corey Huinker wrote:
> +
> +/*
> + * Return the POSIX exit code (0 to 255) that corresponds to the argument.
> + * The argument is a return code returned by wait(2) or waitpid(2), which
> + * also applies to pclose(3) and system(3).
> + */
> +int
> +wait_result_to_exit_code(int exit_status)
> +{
> + if (WIFEXITED(exit_status))
> + return WEXITSTATUS(exit_status);
> + if (WIFSIGNALED(exit_status))
> + return WTERMSIG(exit_status);
> + return 0;
> +}

This fails to distinguish between exiting with (say) code 1 and being
killed by signal 1.

> - if (ferror(fd))
> + exit_code = ferror(fd);
> + if (exit_code)

And this adds even more ambiguity with internal library/system calls, as
Tom said.

> + if (close_exit_code && !exit_code)
> + {
> + error = true;
> + exit_code = close_exit_code;
> + if (close_exit_code == -1)
> + pg_log_error("%s: %m", cmd);

I think if an error ocurrs in pclose(), then it should *always* be
reported. Knowing that we somehow failed while running the command is
more important than knowing how the command ran when we had a failure
while running it.

Note that for some tools, a nonzero exit code can be normal. Like diff
and grep.

The exit status is one byte. I think you should define the status
variable along the lines of:

- 0 if successful; or,
- a positive number 1..255 indicating its exit status. or,
- a negative number N indicating it was terminated by signal -N; or,
- 256 if an internal error occurred (like pclose/ferror);

See bash(1). This would be a good behavior to start with, since it
ought to be familiar to everyone, and if it's good enough to write/run
shell scripts in, then it's got to be good enough for psql to run a
single command in. I'm not sure why the shell uses 126-127 specially,
though..

EXIT STATUS
The exit status of an executed command is the value returned by the waitpid system call or equivalent function. Exit statuses
fall between 0 and 255, though, as explained below, the shell may use values above 125 specially. Exit statuses from shell
builtins and compound commands are also limited to this range. Under certain circumstances, the shell will use special values to
indicate specific failure modes.

For the shell's purposes, a command which exits with a zero exit status has succeeded. An exit status of zero indicates success.
A non-zero exit status indicates failure. When a command terminates on a fatal signal N, bash uses the value of 128+N as the exit
status.

If a command is not found, the child process created to execute it returns a status of 127. If a command is found but is not exe‐
cutable, the return status is 126.

If a command fails because of an error during expansion or redirection, the exit status is greater than zero.

--
Justin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2023-03-09 01:27:04 Re: [PATCH] Align GSS and TLS error handling in PQconnectPoll()
Previous Message Michael Paquier 2023-03-09 01:15:39 Re: Add pg_walinspect function with block info columns