Idea: automatic dotfiles bisection (and minimal example extraction)

Idea: automatic dotfiles bisection (and minimal example extraction)

[Daniel Shahaf]

I'm tired of having to ask people to bisect their zshrc to find minimal
reproducers for bugs they report.

I was thinking, we could write an automatic bisector, similar to
git-bisect(1), which operates on zshenv,zprofile,zshrc, and
automatically reports which statement in those files causes the problem.

A simplistic version would simply split the file by lines, and deal with
the case that a particular split is invalid (say, includes a '{' token
but not its matching '}' token) by trying to split a few lines above or
below, like «git bisect run» does when its argument script exits 125.

A more intelligent version would use the ${(z)} tokeniser to split the
file on statement boundaries.  (It would basically need to keep track of
nesting level into subshells, {…} blocks, and control structures
(done/fi/esac); statement ends are represented as «;» array elements.)

Once "report which line causes the problem to appear" is implemented,
a future feature would be to start weeding out _other_ statements whilst
the problem still reproduces, and thereby automatically construct
a minimal reproduction script. :-)

Does such a thing exist?  Does anyone plan to implement it?

Re: Idea: automatic dotfiles bisection (and minimal example extraction)

[Bart Schaefer]

On Dec 25,  2:51pm, Daniel Shahaf wrote:
}
} I was thinking, we could write an automatic bisector, similar to
} git-bisect(1), which operates on zshenv,zprofile,zshrc, and
} automatically reports which statement in those files causes the problem.

Assorted thoughts:

A place to start might be https://github.com/rocky/zshdb

git-bisect works because it has the git revision history to play with.
Trying to apply that within a single revision of a structured file may
be more trouble than the binary search is worth.

Most difficult is if the error appears inside a multi-line construct,
in which case you have to retain e.g the "done" or "else"/"fi" for
the whole thing to remain valid.  Certain "bisects" would end up
having to have overlapping start/end to be parseable.

So if this is going to be automated anyway, it might be better to
just do it brute force -- start at the end of the file, delete one
statement, if the error is still there put that one back and delete
the one above it, repeat.

For init-file debugging in particular, it might be possible to get a
long way by using a carefully designed PS4, capturing the output of
a full pass through the init file with xtrace, and then examining
that to find line numbers for where to make a clean break.

You're still going to run into trouble if the problem is because of
an option setting where the user has planted a whole list of options
in a single call to "setopt".

Re: Idea: automatic dotfiles bisection (and minimal example extraction)

[Peter Stephenson]

I'm a bit far from the real world to give a full answer conveniently, but I'd be tempted to start from the other end: look ar all the (particularly non-default) options, variables and styles, and play with those until the problem goes away. This is a more tractable target, it seems to me.

pws
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.