[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-bash] Bash Trap: How to Get Line Number of a Subprocess with N

From: Eduardo Bustamante
Subject: Re: [Help-bash] Bash Trap: How to Get Line Number of a Subprocess with Non-Zero Status
Date: Fri, 30 Dec 2016 11:50:11 -0600

On Thu, Dec 29, 2016 at 9:39 PM, Eduardo Bustamante <address@hidden> wrote:
> I'm adding the bug-bash list, since I think this is actually a bug in
> the parse_comsub function, or maybe in execute_command_internal. I
> haven't been able to figure it out yet. What I do know is that these
> two should behave the same:
I'm not sure what was I thinking, but these are of course very
different things (comsub and subshell) :-)

I still think this is a bug, because line number information
(line_number, line_number_for_err_trap and the line attribute in the
different command structures) is handled inconsistently.

The problem is that line information is lost when executing the body
of a function, so what bash does is to store line number information
in the command structures, so that it's able to correctly report to
the ERR trap when it is triggered. But for some reason this is not
handled in a consistent manner for different types of commands, so the
following fail:

- subshells e.g. (exit 17)
- arithmetic commands e.g. (( 0 ))
- conditional commands, e.g. [[ a = b ]]

I don't think this applies for the following types: if, case, for,
arith-for, but I may be wrong.

The attached err_lineno patch is a proposed fix. The reported line
number will be the closing line in the case of a subshell and the
other multi-line constructs. This seems to match the current behavior
when executing outside a function.

Attachment: err_lineno.patch
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]