zypper not working properly with wildcards


Trying to install all “plymouth” themes I did:

zypper in plymouth-theme-*

Waiting for a installation without more problems. However, zypper say didn’t exist any plymouth theme. You can check there is about 6 themes for playmouth.

However, if I try

zypper in plymouth-*

all packages headed with “plymouth”, appeared (even those that zypper didn’t find).

Am I missing something or is a zypper error?

Thank you

zypper in plymouth*-theme*

zypper in plymouth-theme-*

When you type something like this in a shell (bash I assume), the shell is going to do file name expansion on plymouth-theme-*. Thus it depends on what filenames you have in your working directory how that expansion works out. When there are no filenames that answer to that pattern, it is left as it is and given to zypper. And then it is up to zypper what to do with that (I assume you read the docs and think this is a usefull construct for zypper).

When you want to be 100% sure that your plymouth-theme-* is not handled by the shell, but delivered unaltered to zypper, you have to quote it. E.g.

zypper in 'plymouth-theme-*'

When working with the shell, you realy must have some idea what the shell will do with a command before it even comes to starting a program.

Well, I forgot to tell that before my first failed attempt, I tried with single and double quotes, exactly like

zypper in --dry-run "plymouth-theme-*"


zypper in --dry-run 'plymouth-theme-*'

HCVV, I guess you didn’t tried what you answered here ("–dry-run" parameter simulate but not execute the instalation)

However, as Miuku wrote, his solution works!. But, what is the logic in that string?. Mine should be equivalent, but doesn’t work. So, is a bug in zypper?.

I’d say that it is a bug. But maybe it is only a documentation bug (lack of clarity about how to use wildcards).

I did not dry-run or anything.

As long as there are parameters that could be expanded by the shell, there is no way to predict what the statement will expand into without knowing what files there are that answer to the pattern.

That should first be solved before one can take the next step: finding out how the command (the zypper program in this case) should interprete what it gets as arguments. And then of course it could be possible that it interpretes it different from it’s documentation and thus that there is some bug.

But as long as you only try using " … " and ’ … ’ quoting without realy knowing the difference and may be even without understanding why, you will probably not understand why I advise to use shell quoting before jumping to the conclusion that there might b a bug.

Henk, I did read the (poor) documentation about using wildcard with zypper, and based on that, I tried what the logic tell me to try. So I know how it should work and ask here to contrast results about a fact that anyone can see is not a parameter error. But, however, when I answer someone in forums, I check my advice before publish it, and you didn’t do that in this case, and I don’t know why. Maybe cause you didn’t know the use of parameter “–dry-run”. I usually use it when trying to be sure that my answer to someone question about zypper is working. But is my way to do things. Anyway, thank you for your reply


Best regards

nrickert, I agree with you. But I don’t know if zypper programmers read this forum to contrast this point. :confused:

You can file a bug report. It’s okay to include a link to this thread in the report.

openSUSE:Submitting bug reports

Sorry that I am unable to explain to you what I mean. I was not talking about zypper and what it should do with what arguments and if it understands something like "wild cards giving some special meaning to some characters (the * in this case) in those arguments.

I was talking about the fact that when you use “patterns” with a same character (in this case the *) having a special meaning in the shell, it is not unlikeky that the shell does something to that shell “pattern”. And then the * is gone and the shell “pattern” is replaced by the file names that belong to that shell “pattern”. And then zypper would not get that argument with the “wild card” as you intended.

As I was trying to explain what may be done to what you typed by the shell (depending on te files that are in your working directory), there was no need whatsoever to try for myself (in a different working directory) what that statement did.

Sorry, when you stiill not understand this, it is my fault, not being able to explain this over the barrier of language and no face to face contact.

Maybe to convince youu that I am not alone in warnning you for the shell expansion, this is from the example section of zypper’s man page:

Search for YaST packages (quote the string to prevent the shell from expanding the wildcard):
$ zypper se ‘yast*’

Thank you Henk, for that detailed explanation. Effectively, I think this was a “lost in translation” cause, as you discovered without difficulties, I am not very good on speaking English. So if you consider it was your fault, it’s my fault too!!.

I’ll take into account your recommendation in those cases.

Meanwhile, I will send this “bug” to OpenSUSE … THANK YOU nrickert’s for the link.


Note: Is an ancient bug https://bugzilla.opensuse.org/buglist.cgi?quicksearch=zypper%20wildcard&list_id=639711

Yes, it does look that way.

I see that someone (probably you) has just updated Bug 725888, pointing out that the problem is still present in opensuse 13.2.