mIRC Home    About    Download    Register    News    Help

Topic Options
#264259 - 12/11/18 06:49 PM /set in editbox, /var .secs
maroon Offline
Hoopy frood

Registered: 12/01/04
Posts: 969
I came across these issues while replying to the /saveini thread.

(1) When a local %var is created, it clones the .secs value from an existing global var of the same name. Luckily it appears the .secs value is ignored, even when the local scope contains a while() that lasts longer, as the local's .secs isn't getting decremented.

Code:
//set -u2 %x global | var %x local $time , %i 99999 | while (%i) { var %a $sha1(abc) | dec %i } | echo -a $time : secs $var(%x,1).secs local? $var(%x,1).local value $var(%x,1).value vs secs $var(%x,2).secs local? $var(%x,2).local value $var(%x,2).value



(2) In editbox, when /set is used with a single slash, and there is more than 1 space preceding the switch parameter and/or the %var_name, it generates an error and does not set the variable.

Quote:
* /set: invalid parameters


Code:
/var  -s %x test1
/var -s  %x test2
/var  -s  %x test3


I'm not aware of another /command that behaves as if it even notices whether you've used consecutive spaces or not. Though this way does allow setting global variables containing consecutive spaces, it shouldn't need to forbid them preceding the variable name.


EDIT: **

sorry for the typo. I meant for my examples to show using the /SET command not /VAR, which instead is treated as if an invalid command that gets sent to the server, even with the -g switch.


Edited by maroon (12/11/18 10:40 PM)

Top
#264261 - 12/11/18 10:13 PM Re: /set in editbox, /var .secs [Re: maroon]
Khaled Offline


Planetary brain

Registered: 04/12/02
Posts: 4295
Loc: London, UK
Thanks I am aware of both of these. The first is a side-effect of how the unset feature was originally implemented. The implementation has changed over the years, so it might be possible to change this but either way, as you noticed, it has no effect. The second issue is intentional and cannot be changed.

Top
#264262 - 12/11/18 10:35 PM Re: /set in editbox, /var .secs [Re: Khaled]
maroon Offline
Hoopy frood

Registered: 12/01/04
Posts: 969
ok.
And related to the 2nd issue, i didn't mention a similar issue with single-slashed var in the editbox being treated as an invalid command that's sent to the server, since it formerly had no effect without the 2nd slash to evaluate things. However now with the -g switch, /var can have a reason to be used in the editbox without 2 slashes, though in that context it's just something that should be done with /set instead.

Edit:
Correction. when using "/var -g %x 123", it's not the /var that gets sent as the invalid server command, but the -g.


Edited by maroon (12/11/18 11:16 PM)

Top
#264321 - 20/11/18 10:46 AM Re: /set in editbox, /var .secs [Re: maroon]
Khaled Offline


Planetary brain

Registered: 04/12/02
Posts: 4295
Loc: London, UK
Quote:
/var -g %x 123

When I test this in an editbox, the entire /var line gets sent to the server.

This is due to the way /var was originally implemented, as a way of setting local variables in a script. /var is not actually a command in the same way as other commands. It is parsed inline, inbetween other script parser processes, and converted to /set internally. This means that if I did change it to be a normal command, its code would be moved outside of its current parsing sequence, which would likely lead to backwards-compatibility issues.

To prevent /var being sent to the server, I will add a second check for /var as a normal command which will report an error.

Top
#264340 - 22/11/18 07:49 AM Re: /set in editbox, /var .secs [Re: Khaled]
maroon Offline
Hoopy frood

Registered: 12/01/04
Posts: 969
Originally Posted By: Khaled

To prevent /var being sent to the server, I will add a second check for /var as a normal command which will report an error.


Same as in no-beta, in newest beta I'm seeing /var in editbox sending info to the server, just neither sending the 'var' string itself.

Code:
(typed in editbox)
/var %password foobar
/var -s %password foobar


Causes @debug window to show:

Quote:

-> adams.freenode.net %PASSWORD foobar
<- :adams.freenode.net 421 maroon %PASSWORD :Unknown command
-> adams.freenode.net -S %password foobar
<- :adams.freenode.net 421 maroon -S :Unknown command


Top
#264344 - 22/11/18 09:05 AM Re: /set in editbox, /var .secs [Re: maroon]
Khaled Offline


Planetary brain

Registered: 04/12/02
Posts: 4295
Loc: London, UK
I am afraid I am unable to reproduce this issue here. When I type /var in any editbox, I now see the message "* /var: cannot use here". Are you perhaps using a script that is circumventing the normal processing of commands?

Top
#264345 - 22/11/18 09:06 AM Re: /set in editbox, /var .secs [Re: Khaled]
Protopia Offline
Fjord artisan

Registered: 30/08/03
Posts: 216
Loc: UK
Originally Posted By: Khaled
To prevent /var being sent to the server, I will add a second check for /var as a normal command which will report an error.

Not sure that we need an error message - we quite often use /var in an editbox to provide you with examples of bugs.

It seems to me that an editbox line should be treated as an alias (subroutine) and variables treated as local variable until the editbox script terminates when they are deleted.

Top
#264346 - 22/11/18 09:10 AM Re: /set in editbox, /var .secs [Re: Protopia]
Khaled Offline


Planetary brain

Registered: 04/12/02
Posts: 4295
Loc: London, UK
Quote:
Not sure that we need an error message - we quite often use /var in an editbox to provide you with examples of bugs.

Please see above posts. /var unevaluated shows error message because it will be sent to server. //var evaulated is not.

Top
#264347 - 22/11/18 09:12 AM Re: /set in editbox, /var .secs [Re: Khaled]
Protopia Offline
Fjord artisan

Registered: 30/08/03
Posts: 216
Loc: UK
Ah - yes - I forgot about / vs. //.

Top
#264350 - 22/11/18 09:20 AM Re: /set in editbox, /var .secs [Re: Khaled]
maroon Offline
Hoopy frood

Registered: 12/01/04
Posts: 969
Sorry, I had a stray comment in aliases file missing a semi-colon that was behaving like an alias, that formerly was never triggered by //var. I see the cannot-use message now.

Top