Re: RFC: Enabling or disabling tracing shell functions
On 6/6/16 12:50 AM, Dan Douglas wrote: > On Sun, Jun 5, 2016 at 8:48 PM, Chet Ramey wrote: >> "Traced functions inherit the DEBUG and RETURN traps from the calling >> shell." > > Why did RETURN originally get sucked into set -T? Was it supposed to > be primarily for debugging? Yes. The RETURN trap was added to bash 14 years ago as part of the support for the bash debugger. The conditions under which it's inherited are the same as DEBUG. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: RFC: Enabling or disabling tracing shell functions
On Sun, Jun 5, 2016 at 8:48 PM, Chet Ramey wrote:
> "Traced functions inherit the DEBUG and RETURN traps from the calling
> shell."
Why did RETURN originally get sucked into set -T? Was it supposed to
be primarily for debugging? Some functions actually use it for
internal purposes and enabling -T to debug causes (probably unwanted)
side-effects in such cases since there's no way to control their
inheritance separately.
If the goal is to inspect values when a function returns that can be
accomplished with just a DEBUG trap:
trap 'if [[ $LASTFUNC != ${FUNCNAME[0]} ]]; then ...;
LASTFUNC=${FUNCNAME[0]}; fi' DEBUG
Re: RFC: Enabling or disabling tracing shell functions
On 6/2/16 9:20 AM, Paulo César Pereira de Andrade wrote: > Hi, > > This is a "RFC" to update documentation to better match behavior, > or, to get some information about shell tracing. > > Bellow I am quoting a request from an user: > > ---8<--- > The bash shell offers the xtrace (set -x), functrace (set -T) and > function trace (typeset -ft) facilities to control script and function > tracing yet it appears that only set -x is effective, tracing the > calling script + any and all called functions. The problem is faulty assumptions, leading to an incorrect conclusion. Execution tracing uses `set -x, global shell function tracing is `set -T', and `typeset -ft' turns on function tracing for an individual function. The mistake is assuming that function tracing and execution tracing are the same thing. They're not. Function tracing exists primarily for use by the shell's debugging mode, which implements execution tracing and breakpoints using the DEBUG trap; the manual says: "Traced functions inherit the DEBUG and RETURN traps from the calling shell." and "-T If set, any traps on DEBUG and RETURN are inherited by shell functions, command substitutions, and commands executed in a subshell environment. The DEBUG and RETURN traps are normally not inherited in such cases." The rest of the proposal assumes some other meaning for `function tracing' than what exists in bash. This special meaning for -t when used with -f and shell function names could possibly appear in some future version of bash, using another option letter, but it won't happen until at least bash-5.0, if ever. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: RFC: Enabling or disabling tracing shell functions
Not sure exactly how zsh does it but I know not having the option for both global and local tracing can be annoying. The two big ways of handling xtrace I mostly see are either bash's global `set -x` or ksh93's per-function tracing, and it can be annoying to be missing either one. There are tricks for getting the effect of global xtrace and/or DEBUG traps in ksh, but its lack of a BASH_XTRACEFD equivalent means it's sometimes impossible to hide the side-effects of those tricks, so you get messy output. With regards to `typeset -ft`, I don't like it. DEBUG and RETURN have totally different usages. Inheriting RETURN very rarely makes sense, but I almost always want DEBUG inherited because of course it's primarily used for debugging.
