I still think the best solution is figuring out if the platform sed is sane at build time and using a full path (via config setup if being able to change the sed used is a priority). Short of that something as simple as
(git-am:699+)
if test -z "$GIT_AUTHOR_EMAIL"
then
# Can occur when sed in PATH will not handle UTF8 under LC_ALL=C.
gettextln "Patch does not have a valid e-mail address."
stop_here $this
fiwould give folks trying to troubleshoot the problem a clue to what was going on. From the fink developers' list it seems Darwin and perhaps FreeBSD use US-ASCII for LC_ALL=C or POSIX which is why Gnu sed gets it wrong.
My problem is still fixed whatever is decided. Enjoy,
-ljr
---
Lanny Ripple
lanny@spotinfluence.com
On Jun 1, 2012, at 11:19 AM, Junio C Hamano wrote:
Show 34 quoted lines
> Jeff King <peff@peff.net> 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.
>