On Fri, Jun 7, 2013 at 10:18 AM, Jurko Gospodnetić
<
jurko.go...@gmail.com> wrote:
> Hi.
>
> Thanks for replying! I was beginning to think my messages were getting
> lost somehow. :-)
No, they weren't lost. We don't have a strong "support team", this is
more of a "you have to do the heavy lifting yourself (or convince
someone to do it for you)" kind of project. And as the good user you
seem to be, you have shown willingness to do some debugging yourself.
Great :)
>> Hm. POSIX defines -q for grep:
>>
http://pubs.opengroup.org/onlinepubs/009695399/utilities/grep.html
>>
>> But, it seems to do more than just quieting, it also changes the
>> return value in the case of an error. Perhaps this detail is related
>> to your crash?
>
>
> Actually, the return value stays the same. Both with or without this
> option grep should return 0 when it finds something or !0 if it does not,
> and this behavior is good enough for the filter-branch script.
Perhaps. The standard says "If the -q option is specified, the exit
status shall be zero if an input line is selected, even if an error
was detected." Is what you're saying that you inspected the
surrounding code well enough to conclude that "an error was detected"
is irrelevant in this case? Because that condition *does* change from
non-true to true in this case.
>> > Any chance of getting something like this in msysgit?
>>
>> Not likely until we find out *why* this happens.
>
>
> Would adding some sort of a test reproducing this behaviour be enough for
> the fix to be applied?
That would increase the chance of finding out why it happens, so yes.
> That way the end-user problem gets fixed ASAP.
I don't believe papering over problems without understanding them is
the way forward, that'll just leave us with an unmaintainable mess. So
let's focus on the "finding out why"-bit.
Especially since there's a bunch of other places where we do the exact
same thing, and they would probably need inspection too.
> Real underlying reason behind the crash seems to be somewhere deep in
> msys/cmd internals. Could someone with access to a newer msys version try
> out the shell script from my other post (quoted below)?
>
>
>>> #!/bin/sh
>>> fifi () {
>>> /bin/sh -c "echo ...lala..."
>>> }
>>> echo huhu | fifi >/dev/null 2>&1
>>
>>
>> If you run this script from git's bash prompt - everything works fine,
>> i.e. it produces no output and the shell process does not not crash.
>> However, if you save it as 'script.sh' & run it from the cmd shell like
>> this:
>> "C:\Program Files (x86)\Git\bin\sh.exe" ./script.sh
>
Thanks for the reproduction-case.
Running it like that *does* take down the shell here indeed. But we
cannot simply assume that piping all output to /dev/null is broken;
we've been doing this in a dozen different places for years without
problem. Something else is most likely going on.
My first hunch was "well, we don't set up the environment", so I tried
running cmd from sh, and issuing the command there. That succeeded.
But my next attempt was to run it from git-cmd.exe (which AFAIK is
supposed to set up the environment correctly), and the issue still
persists.
So I'm thinking that it's still a configuration issue of some sorts,
there are quite some steps involved in setting up our bash-shell. But
I'm not feeling motivated enough to dig through it all to try to
figure out what the relevant difference is :/
Another data-point: Starting sh interactively, and then running the
script does not cause a crash, it seems.