Zsh Mailing List Archive
Messages sorted by:
Re: Idea: automatic dotfiles bisection (and minimal example extraction)
- X-seq: zsh-users 22272
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: zsh-users@xxxxxxx
- Subject: Re: Idea: automatic dotfiles bisection (and minimal example extraction)
- Date: Sun, 25 Dec 2016 10:37:48 -0800
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:date:in-reply-to:comments:references:to:subject :mime-version; bh=YxU3izpB51ecsl8HaMH/EkHfTjuWpHoPh3HIQfNiddA=; b=y2UjXDhrM3FrTYj6Adq1eW5SxlTHNUUX8Qc5wemcLFExJDTkVDDcdLHRmKaSNpzCOo tdGFx9/czmW5VjXSQLHrnwS+ZEifIZsdGUv4RUU+kZnyUTn8g9UNS1+OOIhN/p06jlW7 8S4tUwoliwlqfng89c0CKsL/NNvepEs6A7Z9OAgSG7NX0Xa9YYrlOvee1Lwfp30uRNI7 7NgI6H3jLuU+Ey6LUOveLJEmGje+mBAK/vSzj6PEWmx2otDVFJ4vhRgBU0ASppnc1U7X a98xjYOjzQ6dYIiuA54vgmcxrB4H6nrWvSgD0jXDM/ANKjf6GU9WZf5w0/x816b3+pBz OCcw==
- In-reply-to: <20161225145145.GA14409@fujitsu.shahaf.local2>
- List-help: <mailto:email@example.com>
- List-id: Zsh Users List <zsh-users.zsh.org>
- List-post: <mailto:firstname.lastname@example.org>
- Mailing-list: contact zsh-users-help@xxxxxxx; run by ezmlm
- References: <20161225145145.GA14409@fujitsu.shahaf.local2>
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.
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".
Messages sorted by: