Re: RFC: Enabling or disabling tracing shell functions

[Chet Ramey]

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

[Dan Douglas]

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

[Chet Ramey]

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

[Dan Douglas]

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.

RFC: Enabling or disabling tracing shell functions

[Paulo César Pereira de Andrade]

  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.

set -x:
Caller and all functions traced, irrespective of typeset [-+]ft and set [-+]T

set +x:
No trace at all, irrespective of trace -ft and set [-+]T

In contrast, using the POSIX shell (HP-UX), the trace directives "set
[-+]x" and "typeset [-+]ft " interact as follows (regardless of
whether shell functions are defined with the "function name" or
"name()" forms):

set -x:
- typeset -ft name ...
Caller and named function(s) traced

- typeset +ft name ...
Caller but trace from named function(s) suppressed

set +x:
- typeset -ft name ...
Only named function(s) traced

- typeset +ft name ...
No trace at all

So function trace can be governed _independently_ of the calling
script/session trace, which is useful in controlling the amount of
trace generated.  Can bash replicate this behaviour, i.e. trace a
script but NOT its called functions ?
---8<---

  Since access to HP-UX sh, that should be a superset of ksh88 is not easy,
one shell that appears to be very close to the HP-UX sh in this respect is
zsh, that allows either tracing or not tracing only functions.

  Looking at bash source code, it could require a significant change to offer
such feature. First, I believe trace_p() would need to be converted to a three
state, to know all the conditions, or, it could by default trace
functions always
and only not trace if trace_p() is unset. The problem is that trace_p() for
functions is already being used for a different state control.

  Assuming the current trace_p() usage were modified, to implement disable
of traced functions, a pseudo-patch could be:

---8<---
make_cmd.c:make_function_def()
-  temp->flags = 0;
+  temp->flags = att_trace;
---8<---

and
---8<---
execute_cmd.c:execute_function()
   restore_default_signal (ERROR_TRAP);
 }

+  if (echo_command_at_execute && !trace_p (var))
+{
+  unwind_protect_int (echo_command_at_execute);
+  echo_command_at_execute = 0;
+}
+
+
   /* Shell functions inherit the RETURN trap if function tracing is on
  globally or on individually for this function. */
---8<---

but to trace only functions under "set +x" a different approach would be
required (the need for a three-state).

  Attached is a test script from the user, that will work with bash and
zsh (to test ksh behavior need to comment the "set +-T").

Thanks,
Paulo


x.sh
Description: Bourne shell script