Deutsch English Français Italiano |
<v67k33$3403d$1@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!news.nobody.at!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Janis Papanagnou <janis_papanagnou+ng@hotmail.com> Newsgroups: comp.editors Subject: Various forms of Regexps in tools (standard and non-standard) (was Re: CLARIFICATION ...) Date: Fri, 5 Jul 2024 04:00:01 +0200 Organization: A noiseless patient Spider Lines: 60 Message-ID: <v67k33$3403d$1@dont-email.me> References: <v613h1$1m6k5$1@dont-email.me> <v63ar5$25gos$1@dont-email.me> <v67gs4$2vq6a$1@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Date: Fri, 05 Jul 2024 04:00:03 +0200 (CEST) Injection-Info: dont-email.me; posting-host="4a580dc781068db1978e0cdfb453c8fb"; logging-data="3276909"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+CZG7Oq4U3gJ8QQWMtOvN8" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 Cancel-Lock: sha1:yMxqd2CnlqP49/WI1AMyjEFgXrs= X-Enigmail-Draft-Status: N1110 In-Reply-To: <v67gs4$2vq6a$1@dont-email.me> Bytes: 4091 On 05.07.2024 03:05, Lawrence D'Oliveiro wrote: > On Wed, 3 Jul 2024 05:57:39 -0500, Richard Owlett wrote: > >> My web reading and a discussion in another forum has may has made me >> aware that there is more than one way to handle regular expressions. I'm not quite sure what you mean by "handle" REs. There's tools with different syntax and that support more or less functions, even sometimes exceeding the class of a Regular grammar (at a given cost). - I suppose you meant this? > > The Perl style seems to have become something of a de-facto standard. Hardly. First, there's differences on the functional level; Perl supports with their regexp library functions that are not part of the Regular Expression grammar class, they exceed that class. The consequence is that for that subset there's no O(N) (linear) complexity guaranteed any more. Second, there's syntactical differences between tools, that are necessary to handle meta-characters in their specific language context; in one tool meta-characters need, e.g., to be escaped where in another context that's not necessary. How can something be a standard when (standard-)tools do not support that. Then there's sometimes syntactical convenience shortcuts in use (here I'm thinking of Perl's escaped classes of common entities and their negated forms); these are very handy especially where these expressions get more complex. Moreover, when speaking about [de facto] "standards"; what would that mean in the light of existing (real) standards, like POSIX, that define behavior of tools and the supported RE implementation (BRE, ERE). And finally shells (like Kornshell) that had since 1988 version an own syntax (not comparable with BRE, ERE, Perl's, syntax), an extension of the "wildcard" patterns. Also back-references, one extension that doesn't guaranteed O(N) any more, had been added later. Only later version supported the ERE syntax in addition to the original Ksh-"patterns". It's know that fans of specific products often use terms like de-facto standard. Readers should be careful when spotting such phrases, they are often nothing but marketing talk. Usually you have requirements and have to make yourself familiar with what the allowed tool chest supports (including the Regexp facilities). Granted, getting familiar is harder than following marketing suggestions. But there's (real) standards (as opposed to "de-facto" standards), so if you're learning the standards (RE oder otherwise) you may apply these in a broader context. And if you have the time and the tools that support these "Perl regexps", yet better, since they make some things appear tidier and add convenient functional extensions. Note that Perl regexps also follow (and extend) the basic syntax of the other standard Regexps mentioned (BRE, ERE), so learning the basics first can never be wrong. Janis