Re: My experiences with Rust

>> On Aug 23, 2025, at 7:13 AM, Anthony Pankov <anthony.pankov@yahoo.com> wrote:
>> On 23 августа 2025 г., 1:32:25 you wrote:
>> ..
>>> For output-only data from kernel TO BE LOGGED, text-only format would be
>>> strictly wanted to read/process using oldies-but-goodies tools like
>>> less, grep, awk, sed and any other thing to handle texts.
>> 
>> I have a conceptual question. How to ensure reliability of recognizing
>> events    coded    in    log    string?   There is no information of all
>> mutations   which  log string can take. 'grep "\d+ dropped"' will
>> do  the job well for "200 dropped" till log string has a form "dropped
>> 100" or "150\s\sdropped". In latter cases event will be missed.

> Great question.  I'm not savvy to that '\d+' (egrep thing?), but
> the problem you presented hits right at the core of this "text v binary output" conversation.

> Certainly, utilities may return data whose structure is not ideal
> for every case, (even as "structure"), but depending on what needs
> to accomplish, there are 50 years of UNIX utilites which can solve a
> diverse number of problems users may face.

> Expanding the case you provided, lets say "myprogram" returns the
> following "structured" output lines:

> $ myprogram
> foo dropped 1/2 foo
> bar sortof double! dropped bar
> baz dropped 2/2 baz
> bang sortof last bang
> $

The spot point of this case  is "myprogram" with well known source . What about "outerprogram"
or any tool from base system?
How  to guarantee that I'll get all events of something "dropped"? Can
I  be sure that "outerprogram" will always preserve output format and
never write line like

 "fatal: dropping all"

 In this case my parser pipeline will completely miss this.


-- 
Best regards,
 Anthony  Pankov                        mailto:anthony.pankov@yahoo.com