Skip to main content
replaced http://unix.stackexchange.com/ with https://unix.stackexchange.com/
Source Link

As lk- said, the -name option of find will treat the argument as a glob, not a regular expression.

Whether a string is interpreted as a glob or a regex or just a plain string depends on what is being used to do the interpreting. It's a matter of context. The string in your example, [Rr]eading[Tt]est[Dd]ata can be evaluated in a number of different ways, but what it is depends on how you are using it. Use it as a glob, it's a glob. Use it as a regex, it's a regex. In the case of the question where this originatedquestion where this originated, the OP described the string as a regex. Therefore we can assume he was planning to interpret it as a regex.

A single character can also be a regex, absolutely. It can also be a string, and it can also be a glob. It could be interpreted as a byte or a tinyint, if you like. It all depends on context.

There are a number of specifications for regular expressions in various forms. BRE and ERE are well documented. PCRE adds scads of functionality. Many regex interpreters will implement, for example, "all of ERE and some of PCRE". Or they'll do ERE minus some feature. If you go by formal specifications, many many tools claim regex-support that turns out to be incorrect or incomplete. Knowing the details lets you adapt your solutions to the collection of functionality available within whatever tool is evaluating your regex.

So ... if you're looking for definitions that "exclude" globs, you're looking at this from the wrong perspective. What it is is determined by how you use it.

As lk- said, the -name option of find will treat the argument as a glob, not a regular expression.

Whether a string is interpreted as a glob or a regex or just a plain string depends on what is being used to do the interpreting. It's a matter of context. The string in your example, [Rr]eading[Tt]est[Dd]ata can be evaluated in a number of different ways, but what it is depends on how you are using it. Use it as a glob, it's a glob. Use it as a regex, it's a regex. In the case of the question where this originated, the OP described the string as a regex. Therefore we can assume he was planning to interpret it as a regex.

A single character can also be a regex, absolutely. It can also be a string, and it can also be a glob. It could be interpreted as a byte or a tinyint, if you like. It all depends on context.

There are a number of specifications for regular expressions in various forms. BRE and ERE are well documented. PCRE adds scads of functionality. Many regex interpreters will implement, for example, "all of ERE and some of PCRE". Or they'll do ERE minus some feature. If you go by formal specifications, many many tools claim regex-support that turns out to be incorrect or incomplete. Knowing the details lets you adapt your solutions to the collection of functionality available within whatever tool is evaluating your regex.

So ... if you're looking for definitions that "exclude" globs, you're looking at this from the wrong perspective. What it is is determined by how you use it.

As lk- said, the -name option of find will treat the argument as a glob, not a regular expression.

Whether a string is interpreted as a glob or a regex or just a plain string depends on what is being used to do the interpreting. It's a matter of context. The string in your example, [Rr]eading[Tt]est[Dd]ata can be evaluated in a number of different ways, but what it is depends on how you are using it. Use it as a glob, it's a glob. Use it as a regex, it's a regex. In the case of the question where this originated, the OP described the string as a regex. Therefore we can assume he was planning to interpret it as a regex.

A single character can also be a regex, absolutely. It can also be a string, and it can also be a glob. It could be interpreted as a byte or a tinyint, if you like. It all depends on context.

There are a number of specifications for regular expressions in various forms. BRE and ERE are well documented. PCRE adds scads of functionality. Many regex interpreters will implement, for example, "all of ERE and some of PCRE". Or they'll do ERE minus some feature. If you go by formal specifications, many many tools claim regex-support that turns out to be incorrect or incomplete. Knowing the details lets you adapt your solutions to the collection of functionality available within whatever tool is evaluating your regex.

So ... if you're looking for definitions that "exclude" globs, you're looking at this from the wrong perspective. What it is is determined by how you use it.

syntax correction
Source Link
ghoti
  • 6.7k
  • 1
  • 17
  • 18

As lk- said, the -name option of find will treat the argument as a glob, not a regular expression.

Whether a string is interpreted as a glob or a regex or just a plain string depends on what is being used to do the interpreting. It's a matter of context. The string in your example, [Rr]eading[Tt]est[Dd]ata can be evaluated in a number of different ways, but what it is depends on how you are using it. Use it as a glob, it's a glob. Use it as a regex, it's a regex. In the case of the question where this originated, the OP described the string as a regex. Therefore we can assume he was planning to interpret it as a regex.

A single character can also be a regex, absolutely. It can also be a string, and it can also be a glob. It could be interpreted as a byte or a tinyint, if you like. It all depends on context.

There are a number of specifications for regular expressions in various forms. BRE and ERE are well documented. PCRE adds scads of functionality. Many regex interpreters will implement, for example, "all of ERE and some of PCRE". Or they'll do ERE minus some feature. If you go by formal specifications, many many tools claim regex-support isthat turns out to be incorrect/incomplete or incomplete. Knowing the details lets you adapt your solutions to the collection of functionality available within whatever tool is evaluating your regex.

So ... if you're looking for definitions that "exclude" globs, you're looking at this from the wrong perspective. What it is is determined by how you use it.

As lk- said, the -name option of find will treat the argument as a glob, not a regular expression.

Whether a string is interpreted as a glob or a regex or just a plain string depends on what is being used to do the interpreting. It's a matter of context. The string in your example, [Rr]eading[Tt]est[Dd]ata can be evaluated in a number of different ways, but what it is depends on how you are using it. Use it as a glob, it's a glob. Use it as a regex, it's a regex. In the case of the question where this originated, the OP described the string as a regex. Therefore we can assume he was planning to interpret it as a regex.

A single character can also be a regex, absolutely. It can also be a string, and it can also be a glob. It could be interpreted as a byte or a tinyint, if you like. It all depends on context.

There are a number of specifications for regular expressions in various forms. BRE and ERE are well documented. PCRE adds scads of functionality. Many regex interpreters will implement, for example, "all of ERE and some of PCRE". Or they'll do ERE minus some feature. If you go by formal specifications, many many tools claim regex-support is incorrect/incomplete. Knowing the details lets you adapt your solutions to the collection of functionality available within whatever tool is evaluating your regex.

So ... if you're looking for definitions that "exclude" globs, you're looking at this from the wrong perspective. What it is is determined by how you use it.

As lk- said, the -name option of find will treat the argument as a glob, not a regular expression.

Whether a string is interpreted as a glob or a regex or just a plain string depends on what is being used to do the interpreting. It's a matter of context. The string in your example, [Rr]eading[Tt]est[Dd]ata can be evaluated in a number of different ways, but what it is depends on how you are using it. Use it as a glob, it's a glob. Use it as a regex, it's a regex. In the case of the question where this originated, the OP described the string as a regex. Therefore we can assume he was planning to interpret it as a regex.

A single character can also be a regex, absolutely. It can also be a string, and it can also be a glob. It could be interpreted as a byte or a tinyint, if you like. It all depends on context.

There are a number of specifications for regular expressions in various forms. BRE and ERE are well documented. PCRE adds scads of functionality. Many regex interpreters will implement, for example, "all of ERE and some of PCRE". Or they'll do ERE minus some feature. If you go by formal specifications, many many tools claim regex-support that turns out to be incorrect or incomplete. Knowing the details lets you adapt your solutions to the collection of functionality available within whatever tool is evaluating your regex.

So ... if you're looking for definitions that "exclude" globs, you're looking at this from the wrong perspective. What it is is determined by how you use it.

typi
Source Link
ghoti
  • 6.7k
  • 1
  • 17
  • 18

As lk- said, the -name option of find will treat the argument as a glob, not a regular expression.

Whether a string is interpreted as a glob or a regex or just a plain string depends on what is being used to do the interpreting. It's a matter of context. The string in your example, [Rr]eading[Tt]est[Dd]ata can be evaluated in a number of different ways, but what it is depends on how you are using it. Use it as a glob, it's a glob. Use it as a regex, it's a regex. In the case of the question where this originated, the OP described the string as a regex. Therefore we can assume he was planning to interpret it as a regex.

A single character can also be a regex, absolutely. It can also be a string, and it can also be a glob. It could be interpreted as a byte or a tinyint, if you like. It all depends on context.

There are a number of specifications for regular expressions in various forms. BRE and ERE are well documented. PCRE adds scads of functionality. Many regex interpreters will implement, for example, "all of ERE and some of PCRE". Or they'll do ERE minus some feature. If you go by formal specifications, many many tools that claim regex-support areis incorrect/incomplete. Knowing the details lets you adapt your solutions to the collection of functionality available within whatever tool is evaluating your regex.

So ... if you're looking for definitions that "exclude" globs, you're looking at this from the wrong perspective. What isit is is determined by how you use it.

As lk- said, the -name option of find will treat the argument as a glob, not a regular expression.

Whether a string is interpreted as a glob or a regex or just a plain string depends on what is being used to do the interpreting. It's a matter of context. The string in your example, [Rr]eading[Tt]est[Dd]ata can be evaluated in a number of different ways, but what it is depends on how you are using it. Use it as a glob, it's a glob. Use it as a regex, it's a regex. In the case of the question where this originated, the OP described the string as a regex. Therefore we can assume he was planning to interpret it as a regex.

A single character can also be a regex, absolutely. It can also be a string, and it can also be a glob. It could be interpreted as a byte or a tinyint, if you like. It all depends on context.

There are a number of specifications for regular expressions in various forms. BRE and ERE are well documented. PCRE adds scads of functionality. Many regex interpreters will implement, for example, "all of ERE and some of PCRE". Or they'll do ERE minus some feature. If you go by formal specifications, many many tools that claim regex-support are incorrect/incomplete. Knowing the details lets you adapt your solutions to the collection of functionality available within whatever tool is evaluating your regex.

So ... if you're looking for definitions that "exclude" globs, you're looking at this from the wrong perspective. What is is is determined by how you use it.

As lk- said, the -name option of find will treat the argument as a glob, not a regular expression.

Whether a string is interpreted as a glob or a regex or just a plain string depends on what is being used to do the interpreting. It's a matter of context. The string in your example, [Rr]eading[Tt]est[Dd]ata can be evaluated in a number of different ways, but what it is depends on how you are using it. Use it as a glob, it's a glob. Use it as a regex, it's a regex. In the case of the question where this originated, the OP described the string as a regex. Therefore we can assume he was planning to interpret it as a regex.

A single character can also be a regex, absolutely. It can also be a string, and it can also be a glob. It could be interpreted as a byte or a tinyint, if you like. It all depends on context.

There are a number of specifications for regular expressions in various forms. BRE and ERE are well documented. PCRE adds scads of functionality. Many regex interpreters will implement, for example, "all of ERE and some of PCRE". Or they'll do ERE minus some feature. If you go by formal specifications, many many tools claim regex-support is incorrect/incomplete. Knowing the details lets you adapt your solutions to the collection of functionality available within whatever tool is evaluating your regex.

So ... if you're looking for definitions that "exclude" globs, you're looking at this from the wrong perspective. What it is is determined by how you use it.

added 522 characters in body
Source Link
ghoti
  • 6.7k
  • 1
  • 17
  • 18
Loading
Source Link
ghoti
  • 6.7k
  • 1
  • 17
  • 18
Loading