On 12/30/2016 12:50 PM, Chet Ramey
wrote:
It's the difference between a simple command, which has a line number, and a subshell command, which does not. The subshell command's line number is derived from the execution context, which is relative to the start of the function. The OP wants the subshell's line number to be absolute, like the simple command's, and not relative to the start of the function, as it is now.
From an end-user's perspective, it is unexpected that the LINENO has the value of the
beginning of the function instead of the line at which the ERR was caught by trap.
While the "inside" of the subshell might have it's own characteristics, the inside must
eventually meet the "outside" of the subshell... at which point, an end user can reasonably
expect that an error is reported in a common-sense way with the line number that is
seen in the script file itself. While the current behavior can be explained, that doesn't
mean it is expected by end users or makes sense.
Using any other line number for LINENO also makes it harder to debug scripts, of course,
since the line number being reported isn't as helpful.
Is there any way this can be fixed... or introduced as a feature (e.g., with some
set -o or shopt flag)? A fix would help out a significant number of people. As it is, a
workaround now is to use:
$(...)
instead of:
(...)
to get the expected behavior. But, this can mean some significant re-writing of code.
Enjoy,
Steve Amerige
Server Science Incorporated
Eggsh: A Powerful and Reusable Bash Scripting Platform, an Open-Source Project
