mIRC Home    About    Download    Register    News    Help

Print Thread
#51187 24/09/03 06:56 PM
Joined: Jul 2003
Posts: 23
R
Ameglian cow
OP Offline
Ameglian cow
R
Joined: Jul 2003
Posts: 23
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..

#51188 24/09/03 07:02 PM
Joined: Jun 2003
Posts: 242
R
Fjord artisan
Offline
Fjord artisan
R
Joined: Jun 2003
Posts: 242
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.

#51189 24/09/03 07:23 PM
Joined: Jul 2003
Posts: 23
R
Ameglian cow
OP Offline
Ameglian cow
R
Joined: Jul 2003
Posts: 23
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.

#51190 24/09/03 07:43 PM
Joined: Jun 2003
Posts: 242
R
Fjord artisan
Offline
Fjord artisan
R
Joined: Jun 2003
Posts: 242
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.

Last edited by r0ck0; 24/09/03 07:57 PM.
#51191 24/09/03 08:08 PM
Joined: Jul 2003
Posts: 23
R
Ameglian cow
OP Offline
Ameglian cow
R
Joined: Jul 2003
Posts: 23
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.

#51192 24/09/03 08:14 PM
Joined: Jun 2003
Posts: 242
R
Fjord artisan
Offline
Fjord artisan
R
Joined: Jun 2003
Posts: 242
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

#51193 24/09/03 08:44 PM
Joined: Jul 2003
Posts: 23
R
Ameglian cow
OP Offline
Ameglian cow
R
Joined: Jul 2003
Posts: 23
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.

#51194 24/09/03 08:58 PM
Joined: Feb 2003
Posts: 2,812
Hoopy frood
Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,812
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


Well. At least I won lunch.
Good philosophy, see good in bad, I like!
#51195 24/09/03 10:52 PM
Joined: Feb 2003
Posts: 810
C
Hoopy frood
Offline
Hoopy frood
C
Joined: Feb 2003
Posts: 810
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.


* cold edits his posts 24/7
#51196 25/09/03 02:30 PM
Joined: Jun 2003
Posts: 242
R
Fjord artisan
Offline
Fjord artisan
R
Joined: Jun 2003
Posts: 242
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.

Last edited by r0ck0; 25/09/03 02:52 PM.
#51197 25/09/03 03:09 PM
Joined: Jul 2003
Posts: 23
R
Ameglian cow
OP Offline
Ameglian cow
R
Joined: Jul 2003
Posts: 23
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.

#51198 25/09/03 03:11 PM
Joined: Jun 2003
Posts: 242
R
Fjord artisan
Offline
Fjord artisan
R
Joined: Jun 2003
Posts: 242
Good point. I guess it's just the same old dilemma of users loading scripts about which they know nothing about.

Last edited by r0ck0; 25/09/03 03:23 PM.
#51199 25/09/03 03:21 PM
Joined: Feb 2003
Posts: 810
C
Hoopy frood
Offline
Hoopy frood
C
Joined: Feb 2003
Posts: 810
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.


* cold edits his posts 24/7
#51200 25/09/03 03:23 PM
Joined: Feb 2003
Posts: 810
C
Hoopy frood
Offline
Hoopy frood
C
Joined: Feb 2003
Posts: 810
Oops, while I was typing the post above, RedAlert has made a very good point already. smile


* cold edits his posts 24/7
#51201 25/09/03 03:28 PM
Joined: Jun 2003
Posts: 242
R
Fjord artisan
Offline
Fjord artisan
R
Joined: Jun 2003
Posts: 242
Both of you made very good points smile

Last edited by r0ck0; 25/09/03 03:30 PM.
#51202 25/09/03 03:37 PM
Joined: Jun 2003
Posts: 242
R
Fjord artisan
Offline
Fjord artisan
R
Joined: Jun 2003
Posts: 242
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.

Last edited by r0ck0; 25/09/03 03:41 PM.

Link Copied to Clipboard