How to debug a script in Elvish?

[edouard-lopez]

related: https://stackoverflow.com/q/55201125/802365

---

When writing shell script I often use the -x flag of bash.

Question

Now I'm playing with elvish and I'm looking for the equivalent of

bash -x ./script

[xiaq]

There is no equivalent to -x of bash, and there isn't any debugger yet.

[krader1961]

I'm not convinced of the need, or value, of a builtin debugger. But something like the -x flag supported by most (all?) POSIX shells to enable command tracing is definitely useful. The devil is in the details. Ksh (Korn shell), for example, does a bad job of making such information useful since it doesn't include any useful context and the output is written to the stderr stream which can cause problems with commands/functions which read the stderr stream. Ideally the Elvish version would write the command trace info to /dev/tty or a destination that is OS agnostic and optionally configurable.

[xiaq]

A tracer and an interactive debugger can be complementary.

I don't use interactive debuggers a lot, and there are two things more traditional CLI debuggers tend to suffer:

• They often have a specialized command language, for managing breakpoints, navigating the call stack, etc.
• The UI is usually quite unintuitive. TUI wrappers often make this easier, but usually requires learning new keybindings.

I feel Elvish has the potential to overcome both problems:

• The debugger can just use Elvish itself as the command language, which the user is already familiar with.

• Elvish's editor already has a CLI/TUI hybrid interface, and it seems promising to build a debugger UI that feels similar to the rest of the editor.

[xiaq]

In a sense, you can think of an interactive debugger in Elvish as a goose that lays golden eggs.

[krader1961]

No doubt an interactive debugger would add value. But, like you @xiaq, I almost never use a debugger other than to examine a process core dump (or kernel crash dump). But I do use the set -x of POSIX shells often; notwithstanding the flaws of that mechanism. Implementing good execution tracing mechanism would be considerably more useful to a broader audience than an interactive debugger. Thus my previous comment wasn't meant to suggest an interactive debugger should never be implemented. Only that an execution tracing mechanism would likely make many more people happy and thus should be the initial focus.

[xiaq]

I agree about focusing on tracing first, it is also simpler to implement.

[krader1961]

The "question" label should probably be removed as this is fundamentally an enhancement request. I've been working on a "debug" package to replace the existing use of the current "logutil" package. Regardless of whether my alternative is ever merged both of them can be used to implement a solution for this request that is superior to the POSIX shell -x behavior by allowing the user to selectively request logging just statements and commands to be executed and where the output is written (so the user doesn't have to risk polluting the stderr output).

[birchb1024]

Can I suggest adding builtin functions for tracing in the style of set edit:prompt = . A function, which if defined, is called before an external command is executed?

i.e.

set trace:before-external = {|cmd| echo $cmd >> /my/special/trace/log }          # trace to a file 

The advantages:

• easy to add
• no additional command switch
• User can decide what to trace and how

Also: The lambda could return a rendition of the command to be executed, Elvish executes that instead. This provides a way for the user to override commands.

e.g.

var my_mock_date = {|cmd|
  if ( ==s $cmd[0] date ) { 
    put [/bin/echo 01-01-1970]
  } else {
    put $cmd
  }
}
set trace:before-external = $my_mock_date