mIRC Home    About    Download    Register    News    Help

Print Thread
$$N behaviour #130193 14/09/05 12:53 AM
Joined: Feb 2004
Posts: 2,019
FiberOPtics Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Feb 2004
Posts: 2,019
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.


Gone.
Re: $$N behaviour #130194 14/09/05 09:44 AM
Joined: Apr 2004
Posts: 759
M
Mpdreamz Offline
Hoopy frood
Offline
Hoopy frood
M
Joined: Apr 2004
Posts: 759
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.


$maybe
Re: $$N behaviour #130195 14/09/05 10:23 AM
Joined: Feb 2004
Posts: 2,019
FiberOPtics Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Feb 2004
Posts: 2,019
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.


Gone.
Re: $$N behaviour #130196 14/09/05 11:23 AM
Joined: Apr 2003
Posts: 701
K
Kelder Offline
Hoopy frood
Offline
Hoopy frood
K
Joined: Apr 2003
Posts: 701
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:

Quote:
/give /me gives $$1 a $$2

The double $$ means that this command will only be executed if a parameter is specified. If you specify only one parameter in the above command it will not be executed. You can also do $$?1 or $?1 which means try to fill this value with parameter one if it exists. If parameter one doesnt exist, ask for it. In the first case the parameter is necessary for the command to be executed, in the second case it isn't.


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

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.

Re: $$N behaviour #130197 14/09/05 11:36 AM
Joined: Jul 2003
Posts: 77
B
bamaboy1217 Offline
Babel fish
Offline
Babel fish
B
Joined: Jul 2003
Posts: 77
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.


hmmm signed by me
Re: $$N behaviour #130198 14/09/05 12:49 PM
Joined: Oct 2004
Posts: 8,327
Riamus2 Offline
Hoopy frood
Offline
Hoopy frood
Joined: Oct 2004
Posts: 8,327
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.


Invision Support
#Invision on irc.irchighway.net
Re: $$N behaviour #130199 14/09/05 01:11 PM
Joined: Sep 2003
Posts: 4,230
D
DaveC Offline
Hoopy frood
Offline
Hoopy frood
D
Joined: Sep 2003
Posts: 4,230
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 frown

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

Re: $$N behaviour #130200 14/09/05 01:40 PM
Joined: Apr 2004
Posts: 759
M
Mpdreamz Offline
Hoopy frood
Offline
Hoopy frood
M
Joined: Apr 2004
Posts: 759
Quote:
I would expect test_2 only to stop if I specified $$test_1 instead of $test_1.

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


$maybe
Re: $$N behaviour #130201 14/09/05 04:37 PM
Joined: Sep 2005
Posts: 2,876
H
hixxy Offline
Hoopy frood
Offline
Hoopy frood
H
Joined: Sep 2005
Posts: 2,876
Nice suggestion, one problem: I'm sure quite a few scripts rely on this feature already. Maybe $$$N? smile

Re: $$N behaviour #130202 14/09/05 04:48 PM
Joined: Feb 2004
Posts: 2,019
FiberOPtics Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Feb 2004
Posts: 2,019
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.


Gone.
Re: $$N behaviour #130203 14/09/05 10:31 PM
Joined: Dec 2002
Posts: 2,962
S
starbucks_mafia Offline
Hoopy frood
Offline
Hoopy frood
S
Joined: Dec 2002
Posts: 2,962
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.


Spelling mistakes, grammatical errors, and stupid comments are intentional.
Re: $$N behaviour #130204 02/10/05 05:49 AM
Joined: Jun 2004
Posts: 65
S
sdamon Offline
Babel fish
Offline
Babel fish
S
Joined: Jun 2004
Posts: 65
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.

Re: $$N behaviour #130205 02/10/05 10:59 AM
Joined: Apr 2003
Posts: 701
K
Kelder Offline
Hoopy frood
Offline
Hoopy frood
K
Joined: Apr 2003
Posts: 701
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.