Consider this example:

alias test_1 echo -a $$1

alias test_2 {
test_1
echo -a -> hmm
}

When issuing /test_2 nothing will happen. This is because no parameter is specified when calling the alias test_1 inside the second alias. However, I feel that using $$ should only stop the alias from processing which holds the $$, in this case test_1.

I think test_1 should not execute (as always when specifying $$N), however test_2 should keep going, in this example echoing "-> hmm".

I'm not really sure if this is even intended behaviour, so I contemplated whether to post in the bug forum or this one. Basically the above two aliases should do the same as this does:

alias test_1 return

alias test_2 {
test_1
echo -a -> hmm
}

When test_2 is called, it first calls test_1 which immediately returns (as with the first example with $$1), however now it keeps going.

Changing the examples to work with return:

alias test_1 return $$1

alias test_2 {
echo -a -> $test_1
echo -a -> hmm
}

This will again not echo hmm, whilst I would prefer that it only stops processing if I specifically stated $$test_1, this gives me more control.

Hmm im not sure about this:

alias test_2 {
echo -a -> $gettok(ha ha ha ha,2)
echo -a -> hmm
}

test_1 just has insificient parameters and therefor test_2 will halt, i think that changing that behaviour will be in huge contrast as to how the rest works.

That's an entirely different situation becuase the $gettok raises an error, which rightfully stops the script from processing. I do not ask for the behaviour of errors to change, but the behaviour of $$n stopping not only the code that holds it, but any higher level code that makes a reference to the alias containing the $$n.

test_1 doesnt have insufficient parameters in the way that it is a problem to stop all processing. Because of the $$1 it simply does not execute the commands inside test_1, in this case "echo -a $$1", but what I find weird with the whole thing is why test_2 needs to stop processing because of that.

I would expect test_2 only to stop if I specified $$test_1 instead of $test_1.

Anyway, thank you for the opinion though.

I think I agree with you. I'll have to check my scripts for instances of $$, because I believed that it would only stop the current alias, not the entire script. This makes me think $$ is implemented using /halt instead of /return. Is it correct or not? The help files says this:



This can go both ways, so it's not helping

Maybe the real feature suggestion is $$ meaning halt as it does now, and something else ( $£ ?) meaning just return $null but don't halt the calling script.

right now it halts without warning or any type of message if theres no parameter passed. I somewhat agree with the suggestion of it returning; however, lord knows how many scripts that would break, my guess is a lot.

It probably would be useful to have it halt just the alias it's in... at the same time, I can see many errors coming up if scripts started sending blank data back to the calling script if that script isn't already set up to handle blank data.

I think I would just not use $$N in your second alias if you want to at least get $null back. Might be more code to use, but it's not difficult code to avoid using $$N.

I'm just not sure I'd agree that it's better to change it rather than leave it alone.

I ran into this ages ago, i assumed it stoped just the called alias at the missing $$N, but as you said ends proccessing at the missing $$N, which is a slight bit different from the alias not running, but im sure you ment this anyway. What really disturbs me is the fact you can replace default commands, and then one of these might have a $$N in that stops processing, so your left with your script just not running, and your scratching your head as to why, you cant even trap it using :error

My end result, i just never never use $$N

In my opinion halting test_2 is right but it not generating any errors is wrong.

Nice suggestion, one problem: I'm sure quite a few scripts rely on this feature already. Maybe $$$N?

Yes, I'm pro having a new kind of feature that works the way I first thought $$ would work. It might indeed break a lot of scripts if the behaviour was changed, so adding a new version would overcome this problem.

I'd say that using $$identifier and having it fail would be indicative of an error in the script and therefore that it should halt. To me, on the spur of the moment having just read this thread (that's a don't blame me if this is stupid disclaimer), it seems perhaps it should trigger either error handling code or perhaps a new special goto-anchor.

realy, honestly, if you have an issuewith a seconed lay alias halting when $$ is used, dont use $$ in second layer aliases. do your checking all in the first layer. If the seconed alias is not vital to the first's operation, dont use $$ in it. Wasnt that the point of $$?

halting the calling process was kinda the point of $$ in the first place.

I didn't realize starbucks_mafia had such problems with $$n. Maybe you wanted to attack someone else in this thread?

It seems that $$'s point is indeed to halt everything, however the help file doesn't clearly say that, causing misunderstandings for some people (examples cfr above). I think we all can live with the current way $$ is handled now, and don't want to change it for compatibility reasons.

Ofcourse I won't use $$ anymore for helper aliases, but I would still like a 'limited $$'. It's like having used /dec %var a log time and then finding out it has some side effect you didn't realize. Then we don't need anyone saying "then don't use it, use /inc %var -1 instead." There are about always multiple ways to do the same thing in mIRC script, it's choosing the shortest or fastest or clearest way that makes it fun.

This is also a feature suggestions forum, so a feature suggestion of something like $$ that only stops the current alias instead of the entire script seems to be ok here.