I did show that sed was broken and have provided a minimal, reproducible test.
I have reported it to the sed maintainers and they are working on it.
A message or comment in the code that seds not properly handling utf8 characters have been shown to be the cause of the problem and that git selects sed from the PATH would have been 100% effective in at least one case. I don't know the troubleshooting skills of the other two people that bumped into the problem so can't comment. Of the billions of people that have not (if it existed) looked at the breadcrumb and weren't led astray it's (would have) also been 100% effective. Can you in turn posit any reasonable way that get_author_ident_from_commit would improperly build author-script short of a bad sed? I guess you could pull out transient or systematic disk error.
You do, in fact, have several solutions. I won't reiterate since they are in the thread earlier. You also have in many cases the valid concern that the solutions would not be backwards compatible. And yes, this sed will get fixed but what then? The next person that gets a sed they don't expect earlier in their PATH will have to go through the same steps.
I do appreciate the assistance that led to the solution to my problem. Thanks for maintaining and making available such a great piece of software.
Regards,
-ljr
---
Lanny Ripple
lanny@spotinfluence.com
On Jun 1, 2012, at 4:30 AM, Jeff King wrote:
Show 27 quoted lines
> [Please don't top-post.]
>
> On Thu, May 31, 2012 at 02:21:16PM -0500, Lanny Ripple wrote:
>
>>>> Perhaps the error message in git-am could be modified to indicate
>>>> sed is a suspect?. E.g.,
>> [...]
>>> Hrm, that does not sound an attractive way going forward.
>> [...]
>> You have three recent instances where people have bumped into this
>> with sed. (And yes on reporting it to the packaging project.) It
>> seems to me leaving a breadcrumb so that folks can figure out what's
>> going on without having to bother the list would be a win for
>> everyone.
>
> 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.
>
> But really, I'd rather just see the broken sed fixed. Where would the
> breadcrumb lead people at this point, anyway? We don't actually have a
> solution besides "uninstall this other, crappy sed". Has the sed bug
> actually been fixed?
>
> -Peff