USER (was Re: exists or similar command to work like grep on file system files)

[Bruce Easton]

On 2/14/14 11:01 AM, Kenneth Brody wrote:
> On 2/13/2014 8:13 PM, Bruce Easton wrote:
>> On 2/13/14 4:33 PM, Kenneth Brody wrote:
>>> On 2/13/2014 3:52 PM, Bruce Easton wrote:
>>>> On 2/13/14 3:30 PM, Kenneth Brody wrote:
>>> [...]
>>>>>         while read name
>>>>>         do
>>>>>             # The "real work" goes here.
>>>>>         done
>>>>>
>>>> Ken, that technique for the script worked fine for me for one 
>>>> iteration
>>>> from the processing table.  I don't know if it's that, in my 
>>>> example, I
>>>> was repeating the call within @menu or something else, but when I 
>>>> tried
>>>> repeating the "call" to the user program by start back at @menu (or 
>>>> even
>>>> just below the user command), it would fail on the first repetition
>>>> (using a while loop like you show here).
>>>
>>> What do you mean by "fail"?
>> In the debugger, clerk would just hang with no error - as if waiting for
>> more input.
>
> Was there more input for it to get?
>
> [...]
>>> You could also do it "the right way" :-) with:
>>>
>>>      while read pattern
>>>      do
>>>          ls -1
>>>          echo "**END**"
>>>      done
>>>
>>> (You need some way for your processing to know that it reached the end
>>> of the output list.  Hence the echo.)
>>
>> Yes that was the problem. The online manual page for this does have a
>> warning at the bottom about looping till EOF, although not how to test
>> EOF.  There is a line in the middle of that page that states "To test
>> for an end-of-file or program termination, put the user program name on
>> the condition line."  which is how I was trying to test for EOF in
>> processing (and that didn't work without the close [userprogramname]).
>
> But you haven't reached EOF, have you?  ("I'm done sending all of my 
> output, and now I'm back at the 'read' line in the script" is *not* EOF.)
>
> How to detect the end of a list whose length isn't known ahead of time 
> is up to you.  Typically, it's done by sending one more string, 
> containing a value which can't appear in the list itself, such as 
> "END" after a list of numbers, or "/END/" in a list of filenames.  
> (Note that, technically, my example above could fail if you were to 
> create a file named "**END**".)
>
> [...]
>
True.  And again, that was the problem corrected by incorporating a 
special signal denoting the end of the output as you exemplified. At 
first I didn't see any use for testing the the program_name on the 
condition line.  But after setting up an example where the input would 
be redirected from a file, I was able to see the condition switch from 
true to false in the processing table.  So that uncovered for me some 
aspects of the versatility of  'user'.  One thing that helped was 
finding forum emails on this subject on or around 10/06/2009 and 03/02/2011.