Re: code not working ..

[Greg Wooledge]

On Wed, Sep 11, 2024 at 02:08:31 +0200, alex xmb sw ratchev wrote:
> btw , unlike ur old sticking to old methods , i blaze the newest ..
> learning ...

There is absolutely nothing new about

    IFS=:
    [[ :${list[*]}: == *:"$matchme":* ]]
    unset IFS

People reinvent this CONSTANTLY.  You're not the first, not by a long way.
It can be also done with case instead of [[, so you see the same thing
in sh, although of course there are no array variables, so it's :$*:
instead of :${list[*]}: -- that's how far back this idea goes.

Now let's talk about why this is worse than a simple loop.

 1) It uses more memory.  You have to make a copy of the *entire* array,
    allocating enough storage to copy every single element, plus n+1
    delimiter characters.

 2) An early match doesn't significantly shorten the run time.  The entire
    array gets copied, up front, every time.

 3) The serialization requires a delimiter character that must not appear
    within any array element.  In some cases, this may be trivial.  Unix
    user names, for example, may not contain colons (because those are
    used as delimiters in the passwd(5) file format).  So if you have a
    list of Unix user names, you know you can use : as a delimiter.

    But in most cases, there is no such convenient character.  This is
    why you're using things like $'\ff' in an attempt to find a "safe"
    delimiter.  But remember, there are data sets where *any* character
    is allowed.  File (path) names are the classic example of this.  A
    Unix path name can contain *any* byte except NUL.  And you can't use
    NUL as your delimiter in a string serialization, because bash
    strings can't contain NUL bytes.

 4) It's complicated to write and difficult to read.  How many tries did
    it take you to get it working?  I know it was more than one.

Sometimes the simple methods are the best, even if they're "old".