Forums Bug Reports 7.04 - & wildcard

the first and only mention of & as a wildcard in the full versions.txt is as follows:



though if you try the following example:



it echoes. this appears to contradict the description since & is matching 'bc' which isn't a word in 'abc'

Not limited to 7.04, as I get the same results in 6.35

Personally, I didn't think of the & as representing a word (ie: having to be separated by a space character).

My thinking was the a& would be the equivalent of a*, but a & b would mean that a word would have to fill the location between the a and the b

Thus does not echo (or at least, not in 6.35)

Possibly a better description in the help file is what is needed here.

Its explained decently here: http://script.quakenet.org/wiki/If-Then-Else

As far as I can tell, its working as intended.

Your example doesn't echo because you're matching a space and "abc" doesn't contain any space, it's not because of the &.
The help file is clear imo, (/help on text) already states it's behavior :

& matches any word

The bug seems only to happen when & is at the end of a word.

//var %a a&c,%b abc | if (%a iswm %b) echo -a will not echo
//var %a a &c,%b a bc | if (%a iswm %b) echo -a will not echo
//var %a a& c,%b ab c | if (%a iswm %b) echo -a will echo (shouldn't)

edit : Thrull, your link doesn't explain anything much than the help file, and no it's not working as intented.

I guess it depends on how you take it. It could stand to mean that & matches a whole word, and therefore has no meaning touching anything else, or it could mean that it matches only word characters and therefore cannot match more than one word, in which case the particular behaviour you're describing would make sense.

Of course even by that second definition mIRC's behaviour isn't consistent seeing as in the wildmasks &c and a&c the & is treated as a literal ampersand.

I suppose there's the age-old 'backwards compatability' argument for keeping things the same, personally if it does get changed one way or the other I'd like to see the second definition for & used, essentially making it equivalent to a \S+ regular expression and making things like a&c match a word beginning with a and ending with c.

The a& check in your example returning true is a bug in my opinion. & should be literal unless separated by spaces. When separated by spaces in a check, it should be treated as a word wildcard.

e.g. - This requires a $2 and cannot have a $3


e.g. - This also requires a $2 and cannot have a $3


Of course, & is also a bitwise operator, so you have to watch how you use it or you risk the wrong interpretation.

It seems like there is some strange behavior if you type the text literally in the if statement, e.g.:



The first alias, test1, will echo "no", while the second alias, test2, will echo "yes". My guess is that it is treating the & as the bitwise comparison operator in the first one.

However, even when placing it inside a variable, only the "a & b" and "a& b" constructs work. "a &b" and "a&b" will not match at all.

Now that we understand what works and what doesn't work, I'd propose that this wildcard SHOULD match on any non-empty combination of non-space characters. This would give it meaning both with or without spaces to either side of it. I don't see any reason to limit its usefulness to only cases where spaces are present on either side of the wildcard character.

I don't really see how the description contradicts the behaviour here. You could easily be looking to match a word starting with "a", in which case "a&" would be your one-word wildcard match.

As for which behaviour is more useful-- imho you have more functionality in being able to do something like "a& iswm abc" than not (see above example), so why change it? If anything, &a and a&b should work too.

the most sensible interpretation of the description ('a wildcard one word match') is that it matches a whole word, not part of a word. why else would he qualify it with 'one'?

regardless, there is flagrant inconsistency in its behaviour which should probably be addressed. and while there is more functionality in what i demonstrated, it could be considered quite undesirable if extended to having & significant everywhere, especially when passing arbitrary user input to an if condition that uses iswm.

I don't see the problem; * and ? are also significant if providing user input to iswm. You would have to escape all three characters either way, the extra matching of <string>& isn't going to change much. Also it's not significant "everywhere", only in the case where it is followed by a space or EOL-- but I'm sure that wasn't your point.

Flagrant is kind of an exaggeration here. "One" doesn't imply "whole", it implies one. "&" certainly matches one word, but so does "a&". There is also no rule that "&" must be delimited by a space, it is only used this way in a single example. Examples are not rules. If you really want to have a semantic discussion about the documentation's intent based on English vernacular, we can also discuss the fact that "&" will match a space delimited string "!!!", which technically isn't a "word".

But more practically, "sensibility" is less important than "usefulness". "a&" is useful in at least a few cases, and useless in zero cases, so there's no reason to get rid of it. Someone who is using "&" to match a "whole" word will never run into the problem with & matching a partial word, so it's not a matter of incompatibility. The only issue that would matter is the "user input" scenario, but as I pointed out at the beginning, it's no less a problem than "?", "*" or a regular use of "&" (which actually occurs far more often than "&" suffixing a word), so it's not specific to &. If it will make you happy, Khaled could update the description somewhere, but given that versions.txt is not really a specification of current behaviour, I'm not really sure why it even matters. A mention of these wildcard matching characters in the help file would be of more use, as well as a proper description of their functionality.

* and ? are significant but they're also standard well-defined wildcards which most users who wish to search using wildcarded text tend be well aware of. i've lost count of the number of times i've introduced someone to & who was already familiar with the usual * and ?. consider a simple example: searching for files using a trigger of sorts; filenames can't contain * or ?, but they certainly can contain &. surely if something were introduced to be used amongst other, well-defined pieces of syntax, it too ought to be well-defined?

and do you really think it is as sensible to interpret 'word' as being an English word (given hyphens, apostrophes and let's not even get started on dictionary lookups) as it is to understand that & should occur space delimited from that explanation and example?

But we're not arguing the existence of "&" here. Whether a user does or doesn't know about & is irrelevant to the issue you're raising regarding the suffix syntax; it would still need to be escaped. To be clear, your problem is with the specific scenario of "a&" matching behaviour, not the existence of "&", right?

Following up your example with filenames, you often see song titles "Jon & James", but I've never seen "Jon& James"-- the latter might exist, but the former is equally problematic. So as I said, if a user wanted to match files they'd have to know about & and escape it regardless of whether it matched a "whole" word or a "partial" word.

I guess the real question here is whether you have a problem with the behaviour or just have a problem with the way it was described? This wasn't clear in your initial post, as you just listed the "contradiction" but didn't say which one you considered "right". I'm all for having the wildcard syntax actually documented in the help file, if that's all you're really suggesting, but I don't see how the current behaviour should be considered a bug.

PS. My point about sensibility is that reading too much into the versions.txt file is irrelevant-- it's not a specification of current behaviour, it's merely an approximation of it. Even the help file isn't always considered specification when it comes to mIRC (the age old help file inaccuracy problems).

my only gripe is with the asymmetry of its implementation. to say & as a prefix is come across more frequently than & as a suffix is worth considering, but doesn't quite excuse the asymmetry and doesn't convince me that this isn't a bug :P the result is unexpected and, i would guess, unintended

Without testing, I don't think you'd have to escape "Jon & James" because & as a word wildcard would still match & in the text (as a space deliminated "word").

That said, I do think that the functionality being extended would be a good thing. & should work in all situations:

a& b - Works for something like "apple b"
&a b - Works for something like "banana b"
a&b - Works for something like "arab"
a & b - Works for something like "a plus b"
a & - Works for something like "a plus"
& a - Works for something like "plus a"

The only issue is "a & b" due to the bitwise operation. I'm not sure how that can be handled, but the rest should definitely work.

right you are, all 3 wildcards match themselves in all conceivable cases which is why if (%var iswm %var) is a tautology :P

and i'm not all that opposed to your suggestion but scripters and script users alike will have to be quite weary of &'s greater significance in wildmatches; would surely warrant an updated description in the help docs

But all the wildcard caracters are documented under /help on text.
The & wildcard match a word and this is working correctly, if you stick a '&' to a word, it should match a plain '&', nothing else.
That's the bug, when you use a & at the end of a word, it's not matching a '&'

edit : the reply isn't for jaytea, of course.

Except "Jon & James" would also match "Jon Ritchie James", or even the song "James" by artist "Jon": "Jon - James". Those might be less likely, but they're certainly possible.

That's true. Chances of it are unlikely (you'd have to be using iswm or add it to the event matchtext), but you're right. I like the idea of an expanded use of &, but not sure how much it's really needed.