Re: optimal expansions?

[Ray Andrews <rayandrews@xxxxxxxxxxx>]

On 2024-04-20 15:54, Lawrence Velázquez wrote:

> The "-P" option tells "print" to interpret prompt escapes like "%B"
> and "%F"
>     
    Right, I remember that now, the '%' escapes.  So there's an
    advantage to using that method I take it. Never used it anywhere but
    in my prompt.  So those escapes are part of the wider world then.
>  (see zshmisc(1)), allowing you to avoid hardcoding ECMA-48
> escape sequences.  The "${pkg//\%/%%}" expansion interpolates the
> package name with all "%" characters escaped.
>     
    Ok, I can parse that now.  

> > Seems we want '-r' most of the time.
> >       
> Yes, unless you actually do want "print" to interpret substrings
> like "\n".  Sometimes you do, sometimes you don't.  If the operands
> are dynamic and not under your control, you generally don't.
>     
    Yup, with me using newlines to split arrays, I had to avoid it. 
    It's almost amusing, I had the newlines thing exactly backwards but
    still managed to make my functions work.  
> That's because Roman's solution uses "read" to stream the output
> from "apt-file" instead of saving it all and postprocessing it.
>     
    Right, it has to be more efficient.  
    

> If speed is a concern...
>     
    Not in practice, it was just a comment.
    ...
> % apt-file search .txt | wc -l
> 138962
> % for x in ray roman awk; do eval time ./af_$x .txt; done >/dev/null
> ./af_ray .txt  39.43s user 1.74s system 102% cpu 40.099 total
> ./af_roman .txt  12.99s user 24.97s system 130% cpu 29.069 total
> ./af_awk .txt  3.08s user 1.02s system 131% cpu 3.131 total
>     
    That's astonishing.  awk that much faster.  And the code is more
    complex to look at.  I'd have expected zsh native code to always be
    faster than calling an external program.  Thereyago.  
    
>