Forums Bug Reports mIRC 7.0 and NUL ("bit bucket")

You're possibly confusing parameters and/or switches? Nul is not nor would it be treated as a command/alias.
Again, nul is not a command/alias, but a device used in place of [device\]filename parameter. A device allowed in mIRC for years.
You apparently either don't know about the efficiency and versatility of /filter, or you didn't have to parse/manipulate large text files as yet.


What is more, one does not put NUL as outfile of a /filter command only to save a few bits of code ("/remove outfile"-command), but mostly because it's the fastest way to get $filtered. It's fast as it's not writing anything to the disk while reading the file.

@drum and hixxy
A switch could preserve the functionality for the future. But it would break a lot of existing scripts if the support for nul as parameter ("outfile") would stop.
While I wouldn't mind a new switch, I hope mIRC is keeping up the support of nul as "outfile" parameter where it's apparently safe to - like in filter and fopen. Heck, mIRC still supports "$readini filename section item" and the like for compatibility reasons...

Here's an interesting screenshot...


Clearly a situation like this NUL takes on all new properties doesn't it.



Is THAT what this is about? Have you no self discipline? This is NOT a legitimate reason to allow write access to system devices. I've never seen anyone write to NUL before from a mIRC script. I've never seen it used at all with Windows. /dev/null I know is used either out of lazyness or as a last resort.

NUL is actually used quite often both in mIRC and in other programs/scripts/etc. Just because you haven't seen it doesn't mean it's not used often. You likely just don't use/need the kind of scripts that would use it, so haven't seen it for that reason. Besides, both speed and efficiency are valid reasons for using/supporting something. Obviously, a switch that does the same would be better, but that doesn't mean that using NUL is wrong or bad.

Before throwing broad generalizations out about how it's useless and not good to do and so on, why not try using it with /filter on a very large text file and compare your results. You'll find that there can be a significant difference in speed on large files (i.e. not just a few milliseconds).

Btw, just because you can name a file with a device's name doesn't mean that you should. So you should never need to try and output to a FILE called NUL.

That's right, the main reason I am adding NUL support for /filter is backwards compatibility.

I use the file handle functions (/fopen, /fseek, $fread, etc; Not $read and /write which are INCREDIBLY slow) or large files. Unlike /filter, you don't have to wait for the file to process for it to finish. You can pause and resume, and give the user the choice of canceling the operation all together.



I have no control what people name there files. Windows will not let you create a file with the name NUL. But it will still appear in the directory if the file exists. But when you read from it it returns EOF. And writing to it will write to the device.

True, I guess there's no point in implementing a new method when there's nothing wrong with the existing method!