Bill Hacker wbh at
Wed Feb 13 15:28:10 PST 2008>	<47b34981$0$856$415eb37d at>	<20080213203349.e9caf15b.steve at>	<47b35e26$0$848$415eb37d at>	<47B36486.5060404 at> <20080213225948.b4257537.steve at>
In-Reply-To: <20080213225948.b4257537.steve at>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 33
Message-ID: <47b37d0a$0$854$415eb37d at>
X-Trace: 1202945291 854
Xref: dragonfly.kernel:12134

Steve O'Hara-Smith wrote:
> On Wed, 13 Feb 2008 22:43:34 +0100
> "Simon 'corecode' Schubert" <corecode at> wrote:
>> Bill Hacker wrote:
>>>>> After all, if use of find or xargs accomplishes the task w/o ill 
>>>>> effects on memory, then what prevents creation of a compiled utility 
>>>>> that has that same sort of 'flavor' of approach  - just hard-wired 
>>>>> from the get-go?
>>>>     It would have to be a shell builtin
>>> An assumption based on legacy.
>> rm() {
> .....
> 	Sweet, it never occurred to me that a shell function would do to
> bypass the exec limit - and I was thinking that some sort of plugin
> mechanism to extend shell builtins would come in handy forgetting that
> there already was one.

Guess even a blind hog can (inspire others to) find an acorn e'vry once 
in a while....

Now if I can figure out what I'm doing that the substitutiuon in the 
case statement doesn't like .. aside from working in ksh on OpenBSD 'coz 
nuthin else is close by at the mo'

WTH - sun's up here in chilly HKG.  Must be bedtime ....



More information about the Kernel mailing list