On Fri, Dec 30, 2022 at 12:32:15AM +0800, Zorro Lang wrote: > > > > This test passes for me both before and after this patch series. > > > > Both before and after, the way this is supposed to work is that in: > > > > bash -c "trap '' SIGBUS; command_that_exits_with_sigbus" > > > > ... bash should print "Bus error" to stderr due to > > 'command_that_exits_with_sigbus'. That "Bus error" is then redirected. Before > > it was redirected to a pipeline; after it is redirected to a file. > > > > I think what's happening is that the version of bash your system has is not > > forking before exec'ing 'command_that_exits_with_sigbus'. As a result, "Bus > > error" is printed by the *parent* bash process instead, skipping any redirection > > in the shell script. > > > > Apparently skipping fork is a real thing in bash, and different versions of bash > > have had subtly different conditions for enabling it. So this seems plausible. > > > > Adding an extra command after 'command_that_exits_with_sigbus' should fix this: > > > > bash -c "trap '' SIGBUS; command_that_exits_with_sigbus; true" > > Thanks for this explanation, I think you're right! > > I'm not sure if it's a bug of bash. If it's not a bug, I think we can do this > change (add a true) to avoid that failure. If it's a bug, hmmm..., I think we'd > better to avoid that failure too, due to we don't test for bash :-/ > > How about your resend this single patch (by version 2.1), to fix this problem. > Other patches looks good to me, I'd like to merge this patchset this weekend. > > Thanks, > Zorro I expect that the bash developers wouldn't consider this to be a bug, since it could only be fixed by removing the "skip fork" optimization entirely. Anyway, the workaround I suggested is simple enough. I just resent the whole series, since it's confusing to have new versions of patches within existing series versions. But only this one patch changed. Thanks! - Eric
