Jeff King <peff@xxxxxxxx> writes:
> [Please don't top-post.]
> ...
> But you have to keep in mind all of the people who will be led down the
> wrong path by your breadcrumb when the failure is caused by a
> _different_ problem. What is the probability that it is helpful versus
> not helpful? If you are going to give advice that sed might be broken,
> you should at least test to see if it is broken and report it.
Eek, do that at runtime in the error code path?
Add something like
suspected_sed_breakage () {
xxxxx=$(printf "\370\235\204\236\n" | LC_CTYPE=C sed 's/./x/g')
if test "x$xxxxx" != "xxxxx"
then
die "Your sed is broken; cannot run $1"
fi
}
to git-sh-setup, and do something like:
. "$dotest/author-script" || suspected_sed_breakage "$0"
in git-am?
The problem I see is that at that point where we have to suspect
something fundamental as sed broken on the platform, we cannot even
trust printf, test, or even the shell itself behaving sanely.
So I would say, although it is a fun thought-experiment, such a test
and breadcrumb is not really worth it.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html