Hi Junio,
First - Thanks so much for your reply!
The original cause was simply running a non-related command.
Specifically I was trying to build some internal software. Our internal
software uses a build build tool from perforce called jam
(http://www.perforce.com/resources/documentation/jam). Similar to the make
build tool this looks up a Jamfile (ergo Makefile) and does the recipe. The
issue is that running `jam` fatally aborts right from the start with an
unintuitive `abort trap: 6` error.
As you can well imagine figuring out what was causing this was pretty
difficult - because both the error was cryptic and so unrelated. I started
backing out my environment until I was able to narrow this down to the
bash_completions file. Further investigation finally nailed it on the
concatenation of the `branch. remote.` line 2165.In summary when the lines
were joined it showed the error, when they were on separate lines everything
processed as expected.
Again - my only change was to shift them ( branch. remote. ) to two
separate lines.
HTH
---
Steven Klass
(480) 225-1112
skl...@7stalks.com
http://www.7stalks.com
On Jul 8, 2013, at 10:32 AM, Junio C Hamano gits...@pobox.com wrote:
Steven Klass skl...@7stalks.com writes:
Hi Folks,
Corrects an Abort Trap: 6 error with completions.
Fixed an issue where the two commands on a single line would cause a
strange unrelated 'Abort trap: 6' error on non-git commands on Mac OSX 10.8.
Signed-off-by: Steven Klass skl...@7stalks.com
Can you explain how/why the original causes abort trap: 6
(whatever it is) and how/why the updated one avoids it in the log
message?
It also is not quite clear when the error happens. Do you mean, by
non-git commands, something like:
$ caTAB
does not complete to cal, case, cat, etc. and instead breaks
the shell?
I am confused. The only change I can see in the patch is that it
makes the argument to this call to the __gitcomp shell function be a
string with tokens separated by LF and HT and no SP (the original
assumes that the tokens will be split by LF, HT or SP, and the shell
function locally sets $IFS to make sure that the change in this
patch does not make any difference). And in many other places in
the same script, the __gitcomp shell function is called with an
argument with LF, HT or SP spearated tokens, e.g.
_git_add ()
{
case $cur in
--*)
__gitcomp
--interactive --refresh --patch --update --dry-run
--ignore-errors --intent-to-add
return
esac
---
contrib/completion/git-completion.bash | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
mode change 100644 = 100755 contrib/completion/git-completion.bash
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
old mode 100644
new mode 100755
index 6c3bafe..d63b1ba
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2165,7 +2165,8 @@ _git_config ()
user.name
user.signingkey
web.browser
- branch. remote.
+ branch.
+ remote.
}
---
Steven Klass
(480) 225-1112
skl...@7stalks.com
http://www.7stalks.com
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
