Thanks for the tips MaSOuD, Jethro_, Dean and jaytea, and thanks for the note Dean :)

so when its gonna be your last comment about my comment? cause you keep answering me

That was my last comment in reply to your troll, not other people's comments. Now, please leave me be and be fed elsewhere.

i thought that was your last comment Jethro_, you cant keep your own word...

Thanks jaytea. I do appreciate that you put this matter at bay with a thorough, humble explanation. ^^ I do hope we have more people like you, to encourage each other upon learning and take criticism as an incentive to strive for improvement, rather than stir something up for disharmony and refusing to swallow his or her darn pride for trivial matters.

Or you could do it with the binary way:

this is a good idea and generally my method of choice, but what you have there won't quite work.

breplace &auto 13 44 10

this will certainly replace $chr(13) with $chr(44), but will do nothing with $chr(10)s since you haven't given it a byte value with which to replace them. modifying the width of a binary variable (for example, removing characters) isn't a trivial low level operation, and it's not something that is made possible with /breplace alone. so this snippet sends "JOIN #chan1,\n#chan2,\n#chan3,\n" to the server, which only succeeds in joining #chan1, but then throws errors "#CHAN2, Unknown command" and "#CHAN3, Unknown command" etc.

you can get around this by also replacing $chr(10) with a comma ('breplace &a 13 44 10 44') or forgoing /breplace altogether and using join $replace($bvar(&auto, 1-).text, $crlf, $chr(44)). the first option sends extraneous commas to the server, in between channels, which are safely ignored. the only conceivable drawback to sending these unnecessary commas is if it causes the length of the overall command to exceed the 512 byte limit imposed on the length of raw messages received by the server. but when's the last time you've send someone send such a long /join line? :P as for Dean's single extra comma, certainly not a bug since it doesn't alter the behaviour or results of the code, and it's an extremely unimportant detail at the end of the day.

as ever you're the only guy who starts the troll thing, i just gave another suggestion
you gave yours, about the binary variables, which is not necessary, since a $regsubex can do it
the comma in the end will not affect the code, and that line will only run in a on connect event, without affect nothing,
so i dont know why are you bothered with an extra comma

Ok, I'm not going to debate this further with your persistent belief in having the comma...before this turns into another troll. This will be my last comment.

Look at it this way, both my example and MaSOuD's don't have the extra comma added at the end regardless of its workability. Why makes it unorthodox to be included? > and by the way, i dont need to give to you valid reasonsFor the record, there is none.

you can consider as "bug" something that will affect the code, itself, which not allow it to work correctly, the last comma will be ignored, and the command will work, so its not a bug

While your common regex example is not considered a failure by design, it will look like a bug pestering the code when you can actually remove it.

Give me a valid reason why you need the last comma for the multiple join targets?

and why remove it, if it will not affect the code in nothing? you will only use it once, on connect, and the last comma will be ignored, so why remove it?

and by the way, i dont need to give to you valid reasons

Give me a valid reason why you need the last comma for the multiple join targets?

your suggestion will just remove the last comma, which will be ignored, if there is no channel after this

join $left($regsubex($str($chr(44),$lines(AutojoinChannels.txt)),//g,$read(file.txt,\n)),-1)

thanks for saying something that i already know, it will works, and cant be considered as fail, the command will be interpreted, and it will work

Your regex example will output all the channels from the text file as

/join #chan1,#chan2,#chan3, with an extra comma at the end.

Hermes, you should do something to turn it off on start event
by the way, the on connect event can be done with the regsubex

join $regsubex($str($chr(44),$lines(AutojoinChannels.txt)),//g,$read(AutojoinChannels.txt,\n))

nice one 7/10

Or you could do it with the binary way:

var %auto AutojoinChannels.txt
bread %auto 0 $file(%auto).size &auto
breplace &auto 13 44 10
join $bvar(&auto,1,$bvar(&auto,0)).text

I think in the ON CONNECT event, you could do like this:

var %x = 1,%chans
while (%x <= $lines(AutojoinChannels.txt)) {
  %chans = $addtok(%chans,$read(AutojoinChannels.txt,%x),44)
  inc %x
}
if (%chans) { join %chans }

So, in this way you're just sending ONE command to join all the channels instead of sending one command per each channel.

Another suggestion: some networks/services are don't support /msg NickServ. Like DALnet; you must type /NickServ or /msg NickServ@services.dal.net... So, it's better to use /NickServ itself.