mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Apr 2004
Posts: 871
Sat Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Apr 2004
Posts: 871
As far as I know, there are currently two shortcomings with variable assignment where the variable ends up being set to a value that is not equal to the input value, even when using the -n switch to /set and /var:

1) There is no way to assign the two-character sequence "" (i.e., two double quotes) to a variable in any way.

2) Variable assignment is known to drop any single trailing space character. In contrast: assigning two or more trailing space characters, leading space characters, and a single space character with nothing preceding it, all works fine.

Both shortcomings have been there for a long time. However, I think it would still be nice to have some way to be able to assign values without any modification. That would make holding and processing arbitrary input a lot less painful.

I think it would make sense to extend the -n switch to /set and /var to support this extra level of preservation, but a new switch would be just as welcome.


Saturn, QuakeNet staff
Joined: Dec 2002
Posts: 5,412
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,412
Quote:
As far as I know, there are currently two shortcomings with variable assignment where the variable ends up being set to a value that is not equal to the input value, even when using the -n switch to /set and /var:

The -n switch is specifically for disabling support of mathematical operations.

Quote:
1) There is no way to assign the two-character sequence "" (i.e., two double quotes) to a variable in any way.

That is because "" is treated as an empty string in core variable-related routines. This was implemented in 1996. Changing this would break scripts that use %var = "" to assign an emtpy value. Currently, if you /set %var "", the "" is converted into an empty value immediately and the variables section shows "%var" and nothing after it. However, if you manually type %var "" into the variables section and then "/echo %var", the "" returns an empty value as well. So the "" conversion is happening at both setting and retrieval. This means that even if a switch was added to /set to mark a variable as an exception to current "" handling, this would break when you next restarted mIRC because the variables file cannot store that information.

We could make the assumption that a scripter would never manually type %var "" into the variables section... in which case a switch, such as -q, could be added to mark a variable as an exception to "" handling.

Quote:
2) Variable assignment is known to drop any single trailing space character. In contrast: assigning two or more trailing space characters, leading space characters, and a single space character with nothing preceding it, all works fine.

That is because tokenization throughout mIRC is based on spaces. A space after a word is treated as a separator and is lost. Anything after the space is appended with a space between it and the previous word. While /set could be extended to preserve the entire line, this would affect all scripts. If a script has a /set/var/variable assignment that happens to have an unintentional space at the end of the value, that space would be preserved, which could change the way the script works.

A switch could be added, such as -p, that specifically allows this.

Joined: Apr 2004
Posts: 871
Sat Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Apr 2004
Posts: 871
That would be great, on both counts.

Down to the details: I personally don't think there would be much use for two separate new switches for those two exceptions. Rather, I for one would prefer to see a single new "preserve input as is" switch that encompasses the current -n switch (which itself would remain as is) as well as the new -q and -p functionality you describe. I think that would cover all practical use cases in the most user-friendly way possible. Then again, others might disagree and I'd be happy either way..


Saturn, QuakeNet staff
Joined: Dec 2002
Posts: 5,412
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,412
Okay, I have added a /set -p switch to handle both changes.

As described in my previous post: the next beta will still treat /set %x "" as setting $null, and this will still appear as just "%x" in the variables file, as has always been the case. The only possible backward compatility issue is if a scripter has manually typed %x "" in the variables file. mIRC has always treated that "" as $null. The next beta will treat that as a literal "".

Joined: Apr 2004
Posts: 871
Sat Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Apr 2004
Posts: 871
Sounds good, thank you!


Saturn, QuakeNet staff
Joined: Dec 2002
Posts: 5,412
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,412
Is this change in the beta working the way you expected?

Joined: Apr 2004
Posts: 871
Sat Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Apr 2004
Posts: 871
It is; thank you!


Saturn, QuakeNet staff

Link Copied to Clipboard