Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!munnari!moncskermit!goanna!yabbie!rcodi
From: rcodi@yabbie.rmit.oz (Ian Donaldson)
Newsgroups: net.bugs.4bsd,net.unix-wizards
Subject: Interrupting find(1)
Message-ID: <334@yabbie.rmit.oz>
Date: Wed, 17-Sep-86 11:56:47 EDT
Article-I.D.: yabbie.334
Posted: Wed Sep 17 11:56:47 1986
Date-Received: Tue, 23-Sep-86 22:01:47 EDT
Organization: RMIT Comm & Elec Eng, Melbourne, Australia.
Lines: 42
Keywords: interrupts
Xref: mnetor net.bugs.4bsd:950 net.unix-wizards:7948

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.