On 2021/7/20 上午8:43, Theodore Y. Ts'o wrote:

On Tue, Jul 20, 2021 at 06:06:00AM +0800, Qu Wenruo wrote:

quoted

I can enhance the next version to do that, but that also means any error
inside the hook will bring down the whole test run.

I don't see why that would be?  We just have to sample the exit status
of the hook script, and if it matches a specific value, we skip the
test.

That's what I expect to do next.

 If the hook script crashes, the exit status will be some other
value, e.g., 128+<signal_number>, 127 if the script doesn't exist, 126
if the script exists but is not executable, etc.

That's the concern I have.

If something crashed, I really don't want that to affect the test case 
itself.

E.g. if some setup is half backed and then crashed, how to ensure the 
test can still run without problem?

But I also understand that, only developers will utilize this feature 
anyway, so it's should be the developers' response to make sure the hook 
runs correctly.

 So we just sample $?
and if it is, say, 83 (ascii 'S') we skip the test; otherwise, we run
the test.  How would an error inside the hook "bring down the whole
test run"?

My original concern would be something like error injection setup.
But that could make the test case fail anyway, thus it shouldn't be a 
concern.

Anyway, I'll add extra comment to README.hook to explicit say, if one is 
using hooks, it's their response to make sure their hook to work as 
expected.

Thanks,
Qu

Cheers,

						- Ted