Re: SWEEP WORKS! searching subdirectories

[Robert Holmgren holmgren@xxxxxxxx]

** Reply to message from Judith Davidsen  on Wed, 24
Jul 2002 00:27:02 -0400


> When do you think v113 might be released? Or is there a
> temporary fix I could use? Just used sse to do a search of
> subdirectories and after I found what I was looking for, I
> had to hit Stop 31 more times to exit the 31 remaining files
> that also contained the term, so any help would be greatly
> appreciated.

Allow me first to object to the word "fix". Nothing is broken. 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
-----------------------------