Re: issues in bash found while creating command result display

[Paul Wise]

On Sun, 2019-04-14 at 17:28 -0400, Chet Ramey wrote:

> That's the number of positional parameters.

Oops, I mean the command number variable \# that is available at PS1
evaluation time but not when PROMPT_COMMAND is run. I was able to
workaround this by deferring the decision to display the status until
the PS1 evaluation time and using math functions to access and store
the command number variable \# to a normal variable.

> Syntax errors set $? to 2. SIGINT at the prompt sets $? to 130. There's
> no way to determine whether or not those exit statuses differ from an
> exit status resulting from a command being run.

I managed to workaround this with some heuristics but it would be much
nicer to be able to properly differentiate between these cases.

> PIPESTATUS doesn't get set until a job completes. $? will be reset to
> 128+SIGNUM when a job stops, since that is what shells do and it seems
> reasonable as a way to let the user know a job suspended. It doesn't seem
> particularly useful to set PIPESTATUS to, e.g., {146, 146, 146} in this
> case, though.

Having the former value of PIPESTATUS when $? has been reset doesn't
seem useful either, I think it would be better to unset PIPESTATUS when
setting $? but not PIPESTATUS if you aren't going to set PIPESTATUS.

> There is no way to distinguish these cases.  There is a lot of convention
> at work here, and convention is that well-behaved programs don't exit with
> a status greater than 128.

Unfortunately I have discovered that the convention isn't respected by
a number of programs so it would be nice to have a feature for this.

> The tool you have is the exit status of the last command.
> From that perspective, there's no difference.

From the perspective of the user of a shell prompt there is a difference.

-- 
bye,
pabs

https://bonedaddy.net/pabs3/

signature.asc
Description: This is a digitally signed message part