Re: Globbing versus regular expressions

On 21.07.2024 09:01, Axel Reichert wrote:

Hi all,
 
a colleague (new to command line wizardry) seemed puzzled by the
existence of both globbing for file names (shell) and regular
expressions for strings (many other command line tools).
 
Since I am familiar with both mechanisms for decades, I never thought
about this "redundancy", but now I think he has a point, even more so if
you are using the "dired" file manager in Emacs, which further blurs the
distinction between mangling text and working on files.
 
Since regexes are (at quick glance) a superset of globs, why not
consistently use the former for both file names and strings? The
few additional keystrokes (.* instead of *) are IMHO easily compensated
for by the more powerful capabilities of regexes.
 
A little reading on Wikipedia showed that both came into popular usage
in the early 70s. So why was globbing not dropped and regexes used
throughout? It seems that ksh93 supports "regex globbing". bash has
"extended globbing", but this seems a clumsy, bolted-on solution. Are
there shells out there which follow a regex-only approach (of this would
be non-POSIX)?
 
Happy for any further insights (technical or historical) shed on this
topic!

As you noticed the two forms came from different sort of sources.
Globbing was originally primitive (*, ?, [...], [!...]), and the
regexps implemented parsing/matching of the Regular Expressions
class of formal languages.

The syntax of globbing made it impossible to switch to BRE or ERE
(the two common forms on Unix systems that supported regexps;
meanwhile there are yet more variants with syntactic sugar, but
also extensions of the class of Regular Expressions, accompanied
with its own caveats). The characters, say, '.' or '?' have just
different meanings. That's why Kornshell introduced extensions of
globbing to support some patterns known from BRE/ERE, for example
*(X) for X*, +(X) for X+, ?(X) for X?, and a few own others, like
@(X) and !(X). At some point, because of the prevalence of BRE/ERE
the supported both forms in cases where regular expressions have
to be parsed.

The Kornshell patterns are (with one subtle corner case) a full
regular expression vehicle, and they are certainly no "subset" of
regexps as the more primitive (historic) globbing functions (that
are still used in most other shells).

You cannot just remove "globbing regexps" because they are used.
Similar with BRE/ERE. You would just break most code; code based
on globbing and code based on BRE/ERE. So I think Kornshell did
it the right way, to support both. And with Kornshell globbing we
can of course also express much more powerful patterns than with
the primitive historic globbing facilities.

But even the Unix regexps have different (meta-)syntax depending
on the tools; the reason is that some characters have a native
meaning, thus the regexp metacharacter has to be marked (escaped)
to get one meaning or the other; sometimes the escape '\' symbol
makes the subsequent character a regexp meta-character, in other
tools it makes it a native non-metacharacter.

So it would make little sense (IMO) if there's "shells out there
which follow a regex-only approach"; they would certainly be non-
standard and most likely of limited use (even if used only in own
restricted ecosystems).

Janis