Yum – Regular Expression or Wildcard Search?

regular expressionyum

5.2. Advanced Searches

If you do not know the name of the package, use the search or provides options. Alternatively, use wild cards or
regular expressions with any yum search option to broaden the search
critieria.

Well, at first I thought that this is simply wrong or outdated, since no known syntax of regular expressions would work with yum search, but then I found this: yum search [cl-*] for example. But it does something otherworldly. It finds things which have neither "c" nor "l" letters in the name or description. (What I wanted is to find all packages, whose names would be matched by cl-.* regexp.

I also found few people suggesting to pipe yum results to grep, which, of course, solves the problem. But, just on principle, I want to find out what did the thing in the square brackets do. What if yum actually can search by regexp?

Best Answer

searching with YUM

You generally don't use any regular expressions (globs) when searching with yum search since the command search is already looking for sub-strings within the package names and their summaries. How do I know this? There's a message that tells you this when you use yum search.

Name and summary matches only, use "search all" for everything.

NOTE: The string [cl-*] is technically a glob in the Bash shell.

So you generally look for fragments of strings that you want with search. The regular expressions come into play when you're looking for particular packages. These are the YUM commands like list and install.

For example:

$ yum list cl-* | expand
Loaded plugins: fastestmirror, langpacks, refresh-packagekit, tsflags
Loading mirror speeds from cached hostfile
 * fedora: mirror.dmacc.net
 * rpmfusion-free: mirror.nexcess.net
 * rpmfusion-free-updates: mirror.nexcess.net
 * rpmfusion-nonfree: mirror.nexcess.net
 * rpmfusion-nonfree-updates: mirror.nexcess.net
 * updates: mirror.dmacc.net
Available Packages
cl-asdf.noarch                  20101028-5.fc19                 fedora          
cl-clx.noarch                   0.7.4-4.3                       home_zhonghuaren
cl-ppcre.noarch                 2.0.3-3.3                       home_zhonghuaren

The only caveat you have to be careful with regexes/globs, is if there are files within your shell that are named such that they too would matchcl-*. In those cases your shell will expand the regex/glob prior to it being presented to YUM.

So instead of running yum list cl-* you'll be running the command yum list cl-file, if there's a file matching the regex/glob cl-*.

For example:

$ ls cl-file
cl-file

$ yum list cl-*
Loaded plugins: fastestmirror, langpacks, refresh-packagekit, tsflags
Loading mirror speeds from cached hostfile
 * fedora: mirror.steadfast.net
 * rpmfusion-free: mirror.nexcess.net
 * rpmfusion-free-updates: mirror.nexcess.net
 * rpmfusion-nonfree: mirror.nexcess.net
 * rpmfusion-nonfree-updates: mirror.nexcess.net
 * updates: mirror.steadfast.net
Error: No matching Packages to list

You can guard against this happening by escaping the wildcard like so:

$ yum list cl-\* | expand
Loaded plugins: fastestmirror, langpacks, refresh-packagekit, tsflags
Loading mirror speeds from cached hostfile
 * fedora: mirror.dmacc.net
 * rpmfusion-free: mirror.nexcess.net
 * rpmfusion-free-updates: mirror.nexcess.net
 * rpmfusion-nonfree: mirror.nexcess.net
 * rpmfusion-nonfree-updates: mirror.nexcess.net
 * updates: mirror.dmacc.net
Available Packages
cl-asdf.noarch                  20101028-5.fc19                 fedora          
cl-clx.noarch                   0.7.4-4.3                       home_zhonghuaren
cl-ppcre.noarch                 2.0.3-3.3                       home_zhonghuaren

So what about the brackets

I suspect you have files in your local directory that are getting matched when you used [cl-*] as an argument to yum search. These files after being matched by the shell, were passed to the yum search command where matches where then found.

For example:

$ ls cl-file
cl-file

$ yum search cl-*
Loaded plugins: fastestmirror, langpacks, refresh-packagekit, tsflags
Loading mirror speeds from cached hostfile
 * fedora: mirror.dmacc.net
 * rpmfusion-free: mirror.nexcess.net
 * rpmfusion-free-updates: mirror.nexcess.net
 * rpmfusion-nonfree: mirror.nexcess.net
 * rpmfusion-nonfree-updates: mirror.nexcess.net
 * updates: mirror.dmacc.net
======================================================================= N/S matched: cl-file =======================================================================
opencl-filesystem.noarch : OpenCL filesystem layout

  Name and summary matches only, use "search all" for everything.

NOTE: The match above was matched against my file's name, cl-file, and not the cl-* as I had intended.

Related Solutions

Does (should) LC_COLLATE affect character ranges

If you are using anything other than the C locale, you shouldn't be using ranges like [a-z] since these are locale-dependent and don't always give the results you would expect. As well as the case issue you've already encountered, some locales treat characters with diacritics (eg á) the same as the base character (ie a).

Instead, use a named character class:

echo B | grep '[[:lower:]]'

This will always give the correct result for the locale. However, you need to choose the locale to reflect the meaning of both your input text and the test you are trying to apply.

For example, if you need to find a particular byte value, use the C locale, which is always available:

echo B | LANG=C grep '[a-z]'

If this doesn't work as expected, it really is a bug.

Grep caret appears to have no effect

To find a space, you have to use [:space:] inside another pair of brackets, which will look like [[:space:]]. You probably meant to express grep -E '^[[:space:]]*h'

To explain why your current one fails:

As it stands, [:space:]*h includes a character class looking for any of the characters: :, s, p, a, c, and e which occur any number of times (including 0), followed by h. This matches your string just fine, but if you run grep -o, you'll find that you've only matched the h, not the space.

If you add a carat to the beginning, either one of those letters or h must be at the beginning of the string to match, but none are, so it does not match.

Best Answer

searching with YUM

So what about the brackets

Related Solutions

Does (should) LC_COLLATE affect character ranges

Grep caret appears to have no effect

Related Question