Re: SWEEP WORKS! searching subdirectories

[Judith Davidsen jdavidsen@xxxxxxxx]

> Allow me first to object to the word "fix". Nothing is broken.

Robert--no imputation of brokenness intended. I meant it in
a more gangsterish way of "putting in the fix," i.e.,
forcing things to go my way. And as you seem to be pointing
out, my way could corrupt a civilized system. I'm gonna have
to give this a good think.

Thanks
Judith

> The SEarch command is indeed stopping when you tell it to; but SEarch is a child of SWEEP,
> and when the child quits, control returns to the parent (SWEEP), which then
> continues to do what you told it to do, namely conduct a SEarch through all
> [sub]directories. So SWEEP goes to the next directory in Z-order, and launches
> another SEarch. SWEEP didn't create 31 subdirectories, you did.
>
> However, if you wish to alter this estimable, disciplined behavior, then here's
> what you might do:
>
> CAll U2. Find frame {{5ch*,ci*,cv*,se*}}. Find the sole instance within that
> frame of the $tring "" -- i.e. GoLabel "S". *Replace*  with the
> following:
>
> XPLeNCODE v2.0
> b-gin [UNTITLED]
> {<}IF{<}VA$WN{>}=={<}PV04{>}{>}[BX_]rs[Q2_]{<}EI{>}{<}PV07{>}
> {<}PRStop{>}{<}EX1{>}
> -nd
> XPLeNCODE
>
> That will Stop it dead -- leaving you exactly where you started, with no found
> file open. Is that really what you want? Wouldn't you also wish to be able to
> "O"pen a found file, and then stop dead? In that case, find the sole instance
> of "" (at the tail end of the frame), and change the  to EX1>.
> LOADHELP to save all changes to the code.
>
> Note! By aborting in this unseemly manner, you prevent SWEEP from cleaning up
> its own act. You will be left with at least one directory, created by SWEEP,
> sitting in another window; you will have to ABort that window manually. Very
> very few U2 frames are permitted to just , which is a kind of "EXit
> Absolute" -- usually only in case of egregious system error. U2 organization is
> hierarchical: parents can call children, which can call grandchildren, etc etc;
> and when each programming "descendant" terminates, control is restored to its
> immediate parent or ancestor, until the original, top-level program terminates,
> at which point control is returned to the user. You will recall, for example,
> that the present procedure calls SWEEP, XMACRO, FUNCTEST, SEarch, and several
> other routines, any of which could be left in an unstable state by this
> disorderly conduct. Memory can be gobbled up that is not released. Variables
> that were hidden may not be un-hidden, which could be poisonous to the current
> editing session. Plus, there are many other frames in U2 that also call the
> enhanced SEarch frame, and I cannot really say what the consequences of an
> absolute EXit will be to them, dire or not -- although the consequences for
> SEarch, run by itself, are nil. Note that these are all *generic* programs --
> robots, actually; they can't/shouldn't be tailored to specific situations (such
> as using SWEEP to do SEarches), but rather are designed to suit any purpose or
> usage you can devise. Now, maybe Carl's narrowly focused SSE can be enhanced to
> do the necessary housecleaning (I haven't studied it), but I tend to doubt that
> there's *any* orderly way to stop SWEEP from persevering to the bitter end of
> your directory tree. Anyway... caveat emptor.
>
> Note that you always have another choice, which is func BK, the BreaK key.
> That stops programs too.
>
> -----------------------------
> Robert Holmgren
> holmgren@xxxxxxxx
> -----------------------------