Bug #1
Short description: when stripping control codes (with $strip) from text, if there is a control code between two spaces, the spaces will not be collapsed properly - the stripped text will appear as containing only one space, but in fact will contain two (or more).
Long description: http://www.wingedspirit.net/mircscripts/archives/002458.html (with example, and a workaround for scripters who run into this problem)

Bug #2:
Short description: when logging the status window using the "include network" and "make folder" options, the status logfiles end up in the wrong folders (subfolders of a folder, rather than subfolders of the main logs folder), unless you do some acrobatic option-setting.
Long description: http://www.wingedspirit.net/mircscripts/archives/002459.html (includes workaround)

I can't be the first one to run into these things, but the search option found me nothing?

The first one isn't what I'd call a bug. Personally I find such behaviour useful.

$gettok, $mid, $left and $right all work in the same way (don't remove multiple consecutive spaces).

To remove multiple consecutive spaces you can use $gettok(%var,1-,32), you could also use /tokenize.

If it's not a bug - surely it should display the multiple spaces when I am, for instance, echoing the variable, or outputting the stripped text to channel? Or at least, mention that this behavior happens in the helpfile?
It's not useful when I'm trying to figure out why a text replacer is only catching text in some instances, when the stripped text looks to be the same... and I have to check the ascii values to figure out what's wrong...

1) The workaround in the page you linked is unecessarily complicated/slow. Here's a better one:Alternatively, you can do a //tokenize 32 %checktext and have $1- filled with the text stripped of multiple spaces.

If anything is a bug it's the fact that commands (for the most part) can't handle multiple spaces. I'd much rather see commands become able to do it than identifiers become unable to do it.

There are feature suggestions and bug reports a-plenty for this, btw.

I wouldnt consider this a bug, the behavour of $strip is just as it is defined to be, $strip() strips burk codes, nothing about double spaces.
I have used this on occasion as follows VAR %text = $strip(blah<space><bold><space>blah) ,to supply me with a double or more spaced text when it has been needed for what ever i was doing.

Edit.
Man between reading the bug report and writting that above 4 replies were loggged!

Collective: *shrugs* Either would make me happy. As long as I don't have to hunt through ascii values to figure out why the heck something isn't working, when it should be obvious.

And I'd love to see a few links to the "bug reports and feature requests a-plenty", since I did run a search (with a generic enough keyword), which found me nothing.

---

DaveC: ok - but if it's proper behavior, it should at least show evidence that it does so, not just pretend there's only one space in the string.

[ETA] Heh, I was replying to Collective and when I went back to the thread after posting you'd posted in the middle.

echo -a $replace(%text,$chr(32),$chr(160))

or to really see em

echo -a $replace(%text,$chr(32),^)

1 2 3 4 5 6

* Collective gets bored.

Make sure to expand the date range.

Yeah, I know how to make them displayed - my problem was that I was not expecting this, and so I had no clue what the problem was or why it didn't work... I echoed the variable to active to check if something had gone wrong, and all still looked fine, "just one space, no reason why it's not triggering". Which meant, for me, spending half an afternoon hunting down the problem.

I did extend the date range. Looking at the search again now, yes, I see those threads in the really long list of results. I couldn't have possibly missed them, since the titles are so descriptive of the problem inside. But miss them, indeed, I did. I'm sorry for not spending more than five minutes hunting through the really long list of search results for relevant threads. Really. Mea culpa.

Now will you stop being patronizing?

mahahaha join the club
I had the exact same thing a while back, but luckly i was also dumping to file so looked at the file and saw the double space pretty quick, i do this for quick strips espically if its like a on *:text: $1- etc tokenize 32 $strip($1-)

I found those 6 in 5 minutes.


I wasn't. Over-sensitive perhaps? (now I am)

Enough, though. The last word is yours, if you want it.

can i have the last word?

ummm errr wellummm hmmmmm (sigh count think of one)

#2
I have those options set, my status logs are in their proper folder.

#2 - Tested several times on a clean (freshly installed, no other options changed, latest version) copy of mIRC, and also had a friend test - unless I followed those exact steps when setting the log options, mIRC would not dump the status logs in the proper folder. Had the problem in 6.03; didn't test in 6.12, but in 6.14 I definitely had to jump through those hoops to set the options the way I wanted them, any other way would not work.

Well, I didn't (and stll haven't) read the "long description with workaround" but my logs are all in the proper dirs, with a clean install. All I did was start mIRC, fill in details, enable the logging options including status windows, then connect.

Really dunno, at this point. Maybe it's in the order you enabled the options - or in the order I enabled the options. All I know that yesterday I was setting up a new copy of mIRC, and I tried several times, the status logs would not end up in the proper subfolder. Was also tested several times by a friend of mine. :|

The log issue should be fixed in the just released mIRC 6.15
54.Fixed log folder bug where a subfolder was incorrectly being created in some situations.