Re: [Help-bash] Filename Expansion: Find Utility vs Bash Shell Pattern Matching

[Michael Convey]

On Thu, Jun 18, 2015 at 12:31 PM, Chet Ramey <address@hidden> wrote:

> On 6/18/15 11:24 AM, Michael Convey wrote:
> > I was attempting to determine which globbing library is used by each
> > program to better make sense of why different programs implemented
> globbing
> > differently.  For example, if find and bash both used fnmatch, then I
> could
> > try to understand how the defaults were set be each program. However,
> I've
> > learned that bash does not use fnmatch, but strmatch -- which is based on
> > an old version of fnmatch. It would be nice if all programs who implement
> > globbing migrated to a common library. The way it is now, it is
> > inconsistent and confusing for the learner. If Linux and related programs
> > (bash, find, etc.) "standardized" more on common libraries, mastering
> these
> > areas would be less time consuming.
>
> ​
On Thu, Jun 18, 2015 at 12:31 PM, Chet Ramey <address@hidden> wrote:
​


> Standardization is the solution here, but perhaps not in the way you
> expect.  The benefit of standards is that they allow you to rely on the
> set of standardized features and expect that those features will work
> identically across all implementations that claim conformance.  It also
> allows you to identify extensions or optional behavior and, depending on
> your needs, use or not use those features as appropriate.
>
> Using common libraries is ultimately less effective because it limits each
> program to the library feature set.  As long as you rely on the
> standardized set of capabilities, bugs aside, it should not matter which
> program you're using or the library code those programs use.



​You make a good point, but using globbing as an example, aren't there
enough similarities that a common library might be more efficient and less
buggy because more developers' efforts/eyes are on one library instead of
divided? Isn't globbing narrow enough that a single library could be
designed/extended/modularized to cover all desired features? This would
likely result in a more consistent experience in functionality and with
configurable options. I realize that standardization is necessary either
way and I'm certainly no expert, so I'm sure there are good reasons for the
current architecture. I enjoy peaking under the hood, but it can be
overwhelming. I really do appreciate all the feedback you, Eric, Greg,
Stephane,  and others have provided on this topic.