Reindl Harald wrote: > schrieb Bob Proulx: > >Reindl, Please play nice. Dave was exactly correct and friendly with > >his response to you. Liberty, tolerance and respect are not zero sum > >concepts. (Stealing the excellent phrase from Judge Robert Hinkle.) > > friendly would have been without the "Umm" and with a link
"Umm..." is a friendly way to say something in English. I usually spell it "Uhm...". It is a sound not a word. It is a very casual way to soften the words. I realize that translations can be hard but please file that one away as being *soft* and *friendly*. If someone says "uhm" or "umm" or other spellings (it is a sound not a word and so has no exact spelling) then it means they are simply trying to put something forward *without* making a strong statement of the imperative about it. You can read it as "Please excuse me but..." > the question was "are there additional chars to escape" and not "should i > write all my admin backends in perl" The additional issue was that you were referencing PHP documentation. Might as well have been referencing Lisp documentation for all of the relevance it had. That was the point I saw being addressed at that point. PHP is a similar syntax that came after Perl but it very much is its own thing and Perl does not derive from it. > >As Dave said, SpamAssassin is written in Perl not PHP. The *Perl* > >docs are the ones you should reference not the PHP docs. > > > > http://perldoc.perl.org/perlre.html > > don't refer to why @ inside a regex rule needs escaping nor are we at perl No. That was in the second reference perldata.html which describes perl data structures including @arrayvariable constructs. The above reference covered the regular expressions being used by SpamAssassin. > low-level by writing SA-rules, otherwise "blacklist_from" would need escape > @ too but they don't - frankly i would even call it a bug No. It is not a bug. It is standard Perl syntax. And instead of trying to write write all of the documentation again in random emails and getting half of it wrong and creating new misunderstandings it makes the most sense simply to reference the perl documentation that covers the topic. If there is something that isn't clear in the reference documentation then it is more than welcome to ask questions about it. That is the best place for mailing list discussion. But at least start with the docs and then work from there. Otherwise we will all be doing duplicate work by having documentation and also having mailing list messages that say almost all same thing but being written quickly will contain errors and will create misconceptions. > >The reason @ needs to be escaped is because in Perl "@array" is a > >string containing an array variable that expands to an array value. > >To be a literal at sign in the string it needs "\@array" and that is > >the Perl syntax. > > > > http://perldoc.perl.org/perldata.html > > don't also show a example of \@ and again i call it a bug to expose that > *low* level to SA-rules in a not consistent way Feel free to complain about my choice of documentation pointer in the above. I admit I didn't do very well with that one. I was trying to find the relevant documentation but that was what I found in the time I had available to respond. Perl is a popular language and has a *lot* of documentation available for it. So much that it can be difficult to locate specific things sometimes. That was the best I could come up with at the moment. Looking a little closer I see this: http://perldoc.perl.org/perlop.html#Regexp-Quote-Like-Operators It states there that m// and s/// are double-quote like operators and therefore will expand variables. Variables are $variable and @variable and other expansions unless quoted. Therefore @ is one of the items that need to be quoted. Along with $ and %. And since I am simply summarizing Perl documentation I may have that wrong. Which is why it is better to read the official documentation. Maybe someone else will come up with a better documentation pointer for variables expanded inside Perl strings. Bob
