I am not negating that, I am fact in laying stress on that.
There they say in fact the same as I say. That it is all to be interpreted by zypper and NOT by the shell. Thus one must escape charactersin that argument that are “special to the shell”.
I am afraid that I now must provide a very basic lesson about escaping.
pass through to the program called (zypper in this case) without any interference by the shell, we must use escaping when any “characters special to the shell” are in that string.
You could do this by escaping only those characters and no others. In this case the $ is the only one that is special to the shell in the argumet, thus
Shall we request that, the Zypper man page be cleaned up with respect to the “Repository Management” section “Variable substitution:” ?
It seems to me that, the issue around protecting the “$” preceding the variable name needs to be cleaned up.
Ditto the use of curly braces if, the variable name is followed by an alphanumeric character or underscore – printable characters such as a dash or a slash are not specifically excluded …
[HR][/HR]Discussion leads to quality – simply accepting never uncovers possible errors …
Sorry, that I will put it bluntly, but you still do not understand it.
The remark about protecting the $ from the shell is only there to be nice to people.
It fact, everybody using the shell should be aware of the fact that having a $ (or any other character that is special to the shell) in a field that is to be offered unaltered as an argument to a program called in a statement should be escaped.
The author of that man page nevertheless thought it would be nice to remember people of that. There is at least one other place where such a warning is made:
Examples:
$ zypper se ‘yast*’
Search for YaST packages (quote the string to prevent the shell from expanding the wildcard).
These are just warnings that should trigger the reader to say something varying from: “Oh yes, of course, I almost forgot” to “that is a complete superfluous remark, do they think I am a noob?”
In other words, the warning is nice, correct, to the point and for some superfluous, but I see no reason to ask for removal.
The curly braces have no connection at all with what we are talking about.
The $releasever is something to be interpreted by zypper. It is never to be interpreted by the shell. In fact we are explicitly quoting so the shell will never see and interprete it.
And there is nowhere in the man page of zypper that { and } are something special it will interprete special.
You seem to think that syntax as used by the shell is also used by all other programs (in this case zypper). This is not the case. The fact that zypper has an implementation of wild cards that is very similar to the “file name expansion” of the shell is coincidental (well it is coincidental on purpose, because it is then easy to understand for those who know the shell file name expansion).
======================
I can only adivise that you sit down, get something to drink and think it over:
the shell is a program that interpretes text lines with a certain (rather conplicated) syntax (and semantics).
zypper is a program that interpretes arguments that sometimes can have a rather complicated syntax.
those two syntaxes are different, even if they may look similar in places.
one may start zypper from the shell (but that is not a must, you can start/fork it from any program you write to do so), and zypper has no knowledge whatsoever about the shell command line used to do so, it only gets it’s arguments (and environment) offered by the shell on it’s start as a process.
the shell has no knowledge about the peculiarities of zypper, it will only build a fork() call for the kernel from the comand line it got, doing all the steps (see below) first.
And about expansion:
Expansion is performed on the command line after it has been split into words. There are seven kinds of expansion performed: brace expansion, tilde expansion, parameter and variable expansion, command substitution, arithmetic expansion, word splitting, and pathname expansion.
The order of expansions is: brace expansion; tilde expansion, parameter and variable expansion, arithmetic expansion, and command substitution (done in a left-to-right fashion); word splitting; and pathname expansion.
IMO everbody should know about these six (6) expansions (as well as how the word splitting before it takes place), else there will lawys be surprises on how “The computer does what you ask for and not what you though you asked for”.
I am finished now. I tried to explain these very basic facts inj different wording several times. When that does nlt help, I apperently failed as a teacher (which I never learned for to be honest).