From: Junio C Hamano <hidden> Date: 2016-06-15 22:53:57
Lanny Ripple [off-list ref] writes:
Perhaps the error message in git-am could be modified to indicate
sed is a suspect?. E.g.,
lanny(master);<work/IdeaProjects/Piper> git rebase master rl-clean292
First, rewinding head to replay your work on top of it...
/sw/lib/git-core/git-am: line 692: Leblond: command not found
Patch does not have a valid e-mail address. (Used /sw/bin/sed found on PATH).
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
lanny((ae6c220...)|REBASE);<work/IdeaProjects/Piper>
Hrm, that does not sound an attractive way going forward.
Do we have to suspect any and all uses of POSIX tools, just in case
somebody installs a broken implementation from random places? Is
sed the only thing that is possibly broken?
By the way, have you filed a bug report to whoever supplied your /sw/bin/sed?
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. And yes, if any and all uses of POSIX tools started showing up with some frequency then I think the same breadcrumb win/win logic would apply.
Enjoy,
-ljr
---
Lanny Ripple
lanny@spotinfluence.com
On May 31, 2012, at 1:33 PM, Junio C Hamano wrote:
Lanny Ripple [off-list ref] writes:
quoted
Perhaps the error message in git-am could be modified to indicate
sed is a suspect?. E.g.,
lanny(master);<work/IdeaProjects/Piper> git rebase master rl-clean292
First, rewinding head to replay your work on top of it...
/sw/lib/git-core/git-am: line 692: Leblond: command not found
Patch does not have a valid e-mail address. (Used /sw/bin/sed found on PATH).
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
lanny((ae6c220...)|REBASE);<work/IdeaProjects/Piper>
Hrm, that does not sound an attractive way going forward.
Do we have to suspect any and all uses of POSIX tools, just in case
somebody installs a broken implementation from random places? Is
sed the only thing that is possibly broken?
By the way, have you filed a bug report to whoever supplied your /sw/bin/sed?
From: Jeff King <hidden> Date: 2016-06-15 22:53:57
[Please don't top-post.]
On Thu, May 31, 2012 at 02:21:16PM -0500, Lanny Ripple wrote:
quoted
quoted
Perhaps the error message in git-am could be modified to indicate
sed is a suspect?. E.g.,
[...]
quoted
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
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:
[Please don't top-post.]
On Thu, May 31, 2012 at 02:21:16PM -0500, Lanny Ripple wrote:
quoted
quoted
quoted
Perhaps the error message in git-am could be modified to indicate
sed is a suspect?. E.g.,
[...]
quoted
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
From: Jeff King <hidden> Date: 2016-06-15 22:53:58
On Fri, Jun 01, 2012 at 08:56:01AM -0500, Lanny Ripple wrote:
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.
Great. Do we know yet which versions are affected?
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.
I assume from bogus commit objects. But I admit I am just guessing, and
don't have data.
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.
When I said:
quoted
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?
I meant that there is not a fix for the _user_ to perform at that point.
The point of a breadcrumb like that is that we are not going to put a
fix into git, so we want to at least give the user a clue that their
system has a problem. But what is their next step after being informed
that their system has a problem?
-Peff
At a guess (I haven't tested) every Gnu sed from 4.2.1 down on Darwin and perhaps FreeBSD. The fink developer looking at the sed giving problems (Gnu sed 4.2.1) says that it gets its charset idea from nl_langinfo() which reports US-ASCII for LC_ALL=C or POSIX (on Darwin, derived from FreeBSD). Since US-ASCII is only 7-bit chars anything accented will break.
-ljr
---
Lanny Ripple
lanny@spotinfluence.com
On Jun 2, 2012, at 11:09 AM, Jeff King wrote:
On Fri, Jun 01, 2012 at 08:56:01AM -0500, Lanny Ripple wrote:
quoted
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.
Great. Do we know yet which versions are affected?