Again, many thanks. I'll probably start putting this in prompt
information over the weekend. And again, alas it removes my excuse to
blame zsh for why my code is so broken in this regard ;-)
On Fri, Sep 5, 2008 at 4:45 PM, Peter Stephenson
<p.w.stephenson@xxxxxxxxxxxx> wrote:
On Fri, 5 Sep 2008 10:11:45 -0400"Rocky Bernstein" <
rocky.bernstein@xxxxxxxxx> wrote:
> It would be great if there were a way to get the subshell level nesting. ksh
> uses .sh.level and bash BASH_SUBSHELL.
(Thought it would; but it's good to get that confirmed.)
the only decision is whether the value should reflect a
logical or an actual subshell. I think the former, since the only
difference is to optimise out an exec when the shell is going to exit
anyway, and I think from the user's point of view that should be treated
identically to a real exec.
I
described my motivation. First as status information, second to let
folks realize that values may have gotten discarded and third to make
facilitate picking up state information to be passed back (without
doing unnecessary work in the majority of the cases where there is no
subshell change.)
I think some in some of the optimization cases it doesn't matter all that much, so I leave it to your judgment.
However,
I find it interesting because I had a discussion about something very
similar with David Korn regarding SHLVL which should be added soon to
ksh. He had the same question because in some cases he optimizes a
recursive shell out if the say the shell call is in fact the last line
of the script. What was done there was to set SHLVL to be exactly what
goes on, not trying to hide the optimization done.
And in that case there is a reason why this is desirable. In a
program such as bashdb when a "quit" is done we may really need to quit
several levels of shells that may have gotten invoked in between.
Suppose you were writing a debugger for GNU Make. You'd have the same issue. Or any program
that might call itself recursively and you don't have control in
between of how many *other* recursive shell invocations might have gone
on.
So
here we need the actual number counting whatever optimization was done,
not the virtual number of shells. And here I don't think it too bad to
have the user aware that an optimization was done. When one debugs
optimized C code in gcc there are corresponding issues that any
competent programmer just needs to be aware of. Like in-lined functions
or statements which appear out of order because that's the way assembly
code was reorganized.