🚀 go-pugleaf

Ever wondered why its difficult to abort find(1) during -exec processing?

ie:	find / -print -exec ls -l {} \;
 	^C
	^C
	^C
	aarrgh! its still not stopped!

You usually end up having to hit ^C (or DEL if you prefer) several times
in order for it to stop.  The only reliable way of stopping such a
command is to ^Z it and use kill(1).

This is because there is a piece of code in there that does basically this:

		if(fork()) {
			oint = signal(SIGINT, SIG_IGN);
			oquit = signal(SIGQUIT, SIG_IGN);
			wait( for the -exec process to finish );
			signal(SIGINT, oint);
			signal(SIGQUIT, oquit);
			}
		else {
			handle the exec'd process
			}

Chances are that when you hit ^C, the wait() is in process, and will
end up killing the exec'd process, but the interrupt is ignored by
find(1), and so it proceeds on its merry way exec'ing more things...

The fix would be simply to change SIG_IGN to SIG_HOLD in both statements.

I suspect the same thing happens with find(1) under SVR2 systems, 
but their ain't much you can do about it since there's no SIG_HOLD mode 
under SVR2.

This behaviour was observed with 4.2bsd find(1) on both a Sun-2 and a Vax-750.

I hope that 4.3 has it fixed.

Please forgive me if this has already been brought up.

Ian Donaldson.