Add a way to toggle debug mode in Fish shell #3427
Based from How to toggle debug mode in Fish shell?
I'm aware of how to debug fish script?, but I would like to toggle debug mode in a more precise way, e.g. inside a function.
Would you mind implementing such future?
The text was updated successfully, but these errors were encountered:
As always, we probably shouldn't mindlessly copy the thing bash does. In this case we actually can't use
But first, let's look at what bash actually does. I've never used it much, so this is kinda new to me and I might miss a bunch of subtleties.
> set -x > echo $test + echo > test=foo > echo $test + echo foo foo > false + false >
What immediately seems lacking here is that neither return status nor the exact commandlines before expansion are printed, which might be quite useful.
It also seems like bash has a "BASH_XTRACEFD" variable that can be used to send this debug output somewhere else, which seems quite useful but takes a file descriptor instead of a file name.
Now to what we already have. There is the "-d" or "--debug-level" option, which is lacking in a few ways:
Now, I know @krader1961 wanted to do some reorganizing regarding our debug levels - I can't see much of a difference between debug level 2 and 3 - but I still don't think that'd solve it.
So, how might this look? Let's assume you turn on debugging somehow (via an environment variable?), and then you run
It would output something like
Running `somescript someval` (from commandline `somescript $somevar`) Status: 0 Running `and someotherscript` Status: 1 Skipping `and yetanotherscript`
I.e. the "from commandline" is only output if there has been an expansion.
Note that this can also be enabled via
There's a developing consensus on some related issues to augment
With lexical scoping only the statements in the
Personally, I'd prefer
Also, I like my bikesheds blue.
However, I can see this route not being entirely optimal - if you used it to interactively debug a certain function, you'd do
Also, I can't see any case where you'd always want tracing on, because it, unlike the
However, that slight awkwardness might be offset by having consistency with the other options.
Fine with me.
Better to be explicit
Just a comment that in bash you can get the line numbers while debugging by adding the following:
I add this first thing, to the top of all my bash scripts
Maybe a syntax something like:
would make more sense and also would be explicit.
Also a comment regarding my previous comment on line numbers . The PS4 is the debugging trace line prefix in bash. One of bash's prompts. Maybe a syntax for adding line numbers to the debug if that is not the default would be to add `--debuglinenumberson` or something shorter at the topp of the script.
The bash documentations says:
I'm eager to implement this. A few questions we need first:
Should the interface be a block-scope argument (
I'm leaning towards a variable. The reason is that a variable gets a lot of flexibility for free via the scoping:
The downside is that it's somewhat harder to use options with a variable. For example if we wanted to control the tracing output we would need to somehow encode that in the value of the variable (
When to print
bash prints commands after expansion but before execution. Example:
The advantage of printing before running is that long-running commands get printed. The disadvantage is that you can't see the exit status, which would be really useful in debugging. I'd like to find a way to trace both the exit status and the command itself.
What to print
bash and zsh expand the $PS4 variable like a prompt and prints that. zsh has substitutions like
My sense is that rather than providing a DSL here, we should just have different trace levels:
and so on.
FWIW bash also has a
Printing after execution is much worse if command outputs anything.
I think if you print only non-zero exit statuses, it's fine to print them on a separate line after command exists.
There are 2 neat aspects to this:
This adds support for `fish_trace`, a new variable intended to serve the same purpose as `set -x` as in bash. Setting this variable to anything non-empty causes execution to be traced. In the future we may give more specific meaning to the value of the variable. The user's prompt is not traced unless you run it explicitly. Events are also not traced because it is noisy; however autoloading is. Fixes fish-shell#3427
Thank you for adding this feature. It's very useful in a variety of situations.
[Edit by @faho: Because this keeps being confused: These are not implemented]
For a debugging tool such as
And so on.