mIRC Homepage
Posted By: RedAlert New command: /ialset - 24/09/03 06:56 PM
The search option returned nada on this, so here goes..

I'd like this command to be added:

Code:

/ialset <nick> <user> <host>

(or <user@host>, but that's besides the point)

This command would add an entry to the IAL, provided the specified nickname shares any channels with you. That is, it would function exactly as when mIRC updates the IAL based on incoming data.

This would enable scripters to efficiently utilize the "new" /who raw 354 that at least Undernet and Quakenet support; and, for that matter, it would provide a convenient workaround for any other "this command doesn't update the IAL" complaints in the future (there have been a few in the past, IIRC).

Feedback appreciated..
Posted By: r0ck0 Re: New command: /ialset - 24/09/03 07:02 PM
In mirc.hlp, Khaled mentions guarantees the integrity of the IAL, ie. that a specific nickname is associated with a specific address.

IMO this would seriously compromise the integrity of the IAL.
Posted By: RedAlert Re: New command: /ialset - 24/09/03 07:23 PM
Could you elaborate on that? As far as I can see, one would only be able to "compromise the integrity of the IAL" by adding wrong user+host data to correct nicknames with this command, based on the very nature of the IAL. Why would anyone want to do that deliberately? ...as opposed to accidentally (scripting errors), in which case nothing would be safe.
Posted By: r0ck0 Re: New command: /ialset - 24/09/03 07:43 PM
Quote:
adding wrong user+host data to correct nicknames with this command


You said it yourself right there. When I said "compromise the integrity of the IAL" I didn't mean your pc will blow up.

When you refer to your IAL for information .. do you not want it to be correct, uncorrupted information? I want it to be correct. Thus, I want to preserve the integrity of my IAL.

/ialmark is about as far as I would want to go as far as fooling with the IAL .. at least it doesn't touch the address information. The IAL gets updated (as long as it's enabled) with the majority of remote events. Also, /who & /whois, and I believe even /userhost all update an address(es) in the IAL, with correct/current information.
Posted By: RedAlert Re: New command: /ialset - 24/09/03 08:08 PM
I suggested this command because I want to add 100% certainly correct information to the IAL, based on server data mIRC can't recognise - see my original post. With that in mind, I really don't see your point. And yes, I am perfectly aware of how the IAL works, thank you.

Anyway, just as for all other commands - if you don't know how to use this command correctly, simply don't use it. You don't have to.
Posted By: r0ck0 Re: New command: /ialset - 24/09/03 08:14 PM
I said it would compromise the integrity of the IAL. I did not say it would be a useless command. It would be very useful. It would also be useful to some malicious scripter who might sneak it into a script or addon and start distributing it and start screwing up many newbs IALs. Although this would not harm the newb user or their machine, this would compromise the integrity of their IAL.

End
Posted By: RedAlert Re: New command: /ialset - 24/09/03 08:44 PM
Quote:
It would also be useful to some malicious scripter who might sneak it into a script or addon and start distributing it and start screwing up many newbs IALs.

*laugh* well, if you're arguing for adding a warning for possible "abuse", along with the command, in the mIRC helpfile, I'm not disagreeing with you. The helpfile should reflect how mIRC works - although (in reply to your first post) I don't think it should dictate how mIRC should work.
Posted By: Raccoon Re: New command: /ialset - 24/09/03 08:58 PM
I agree that this this and every mIRC command could be used maliciously, thus I think we have to think twice about using that arguement unless it can be abused by other IRC users that dont have direct access to your harddrive.

Once a user has direct access to your harddrive, via stupid people downloading harmful scripts or otherwise... all bets are off and "potential misuse" shouldn't be an issue.

You can abuse *every* command if you put your mind to it.

- Raccoon
Posted By: cold Re: New command: /ialset - 24/09/03 10:52 PM
Compared to almost all other commands, I can't see how evil this one could be, so I second this suggestion. I'd use it sometimes.
Posted By: r0ck0 Re: New command: /ialset - 25/09/03 02:30 PM
I too don't think it could be evil and maybe I stressed the danger of it a bit too far. The only danger I meant was corrupt information (more of a nuisance than a danger), be it by accident or not. I imagine this is the same reason why built-in identifers have priority over custom identifiers with the same name. But Raccoon does make a good point about abuse of any command. I could see myself using a command like this, but if it were added, I would suggest maybe something like not being able to make it silent so that it is known by the user when it is used. Perhaps a message to the status window:

[09:35] * Address for nick set to: [email]user@host[/email] (line 123, script.ini)

Or something to that effect. Just a thought.
Posted By: RedAlert Re: New command: /ialset - 25/09/03 03:09 PM
Quote:
I would suggest maybe something like not being able to make it silent so that it is known by the user when it is used

Well sure (I don't agree, but it's your suggestion), but in that case, that should be done consistently with all commands that are "dangerous", starting with for example the /sock* family; since, as you may know, sockets can actually be used to do things that are considered illegal in some countries.
Posted By: r0ck0 Re: New command: /ialset - 25/09/03 03:11 PM
Good point. I guess it's just the same old dilemma of users loading scripts about which they know nothing about.
Posted By: cold Re: New command: /ialset - 25/09/03 03:21 PM
Well, taking your example, I don't think it would need an such an "extra protection". I wouldn't like to be forced to read that information when I don't need/want it. I'd rather read a good warning in its section of the help file so I should only use the command when I know exactly what I'm doing and can realize the consequences. If anything goes wrong, I should know it might be the /ialset; use /ialclear and the issue is gone.

Like with /fopen. The help file says you should always /fclose your opened files after they have been used to make them available to other applications. Also, you should check $ferr, $feof etc. yourself. If you don't understand how to use them, you're clearly warned not to use them. Yet, you don't see any /.f* command (and related identifiers) displaying anything by force, unless an usage error (like /fopening the same name twice) occurs.

IMO, /ialset could follow this behaviour, then it should be fine.
Posted By: cold Re: New command: /ialset - 25/09/03 03:23 PM
Oops, while I was typing the post above, RedAlert has made a very good point already. smile
Posted By: r0ck0 Re: New command: /ialset - 25/09/03 03:28 PM
Both of you made very good points smile
Posted By: r0ck0 Re: New command: /ialset - 25/09/03 03:37 PM
Maybe add text warnings for all potentially dangerous commands .. but add an option to enable/disable command warnings (enabled by default of course) .. just another thought.

Edit: Of course being able to enable/disable only in options dialog or script editor options menu. And maybe no warnings if command is issued from the command line.
© mIRC Discussion Forums