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

Worked up to v6.35, now throws an error (unable to open file '<mircinidir>\nul'):
I'm aware that strictly speaking this does not classify a "bug", it's always been some kind of "hack". Yet a couple of scripts used the "nul device" this way, and I'd like to know wheter v7+ cold keep on supporting "nul"?

Thanks

This is probebly due to the file handling changes that where done to mIRC 7.0

It’s actually not a hack “nul” (also known as /dev/null on linux) is a special file that whatever is being written to it will be discarded.
For more information see: http://en.wikipedia.org/wiki//dev/null

Thanks, I already know what "nul" is. That's why I called it "bit bucket" and "nul device" in my post.
I called it a "hack" (mind the quotation marks) only as you cannot suppose every app to accept nul on a "higher level", like MSL. You can ask for it though - especially if the app allowed for nul in the past.

This one is tricky to resolve. All file access is now standardized across mIRC and is handled by one set of routines. These routines prevent device name access. In previous versions of mIRC, the device name check was inconsistent across routines, with some checking and others not. By default, it is safer for this check to be enabled to prevent random freezes/crashes. While it would be possible to exclude certain commands/identifiers/features from this check, that would lead to inconsistency across features again.

Pity to hear that
I understand that the same routines should be used consistently, with no command excluded from a check that can prevent crashes/freezes. Would it instead be possible to add "nul" as an exception (allowed device) to these routines?

Well, Khaled said that would lead to inconsistency again. Since nul is mainly only used with /filter, I wonder if it would just be easier all around to have a switch for /filter that would act like nul?

What Khaled said was that allowing access to devices *in general* can cause freezes/instabilities. I don't think he specifically said allowing NUL anywhere outside filter would cause any issues, and I'd bet NUL is a specific device that should not lead to any freezes/instabilities with any commands, so it could always be exempted globally. This is all pending tests, of course, which could be easily done.

I use for these situations filter -fk somefile $ somematchtext.

It's not that clear cut unfortunately: different devices will react differently depending on whether they are opened for reading or writing. So it might be safe to open "nul" for writing, while reading from it might cause problems. The opposite might be true for another device. To complicate matters, devices may react differently under different versions of Windows.

For the time being, I have added "nul" as an allowed "write" device to /filter.

I don't think this is necessary. Doesn't the following method provide the same result, and is perhaps even more efficient than using nul?

That's a valid workaround. However, NUL seems to perform faster than -k to return/noop or the like (admittedly I only did some *rough* tests).
In any case, my main concern was to maintain consistency, if possible. That is, compatibility of existing scripts, without constrains to the improvements of v7+.
While I cannot assess whether or not there are scripts that used NUL other than in /filter, I myself used it in the /filter command only, hence I am happy with the sollution proposed by Khaled.

@Khaled: Thanks!

This is not a good solution because people use NUL in a number of other identifiers, more notably /debug in order to pipe everything to an alias and discard it afterward.

I thought file handling was changed to be consistent all across mIRC. However /debug still seems to be able to use special devices.

If NUL is able to handle writes without issue, maybe it would be better just to allow it globally? /write, /filter, /debug, etc...

If there are no stability issues (and I can't imagine there being any since this device is specifically meant to take write data), it shouldn't be blocked.

Drawback of using 'return' is that, if the user has Identifier warning checked, it causes for every line an error "* No such identifier: $return". This does not happen with '$' as filter target.

Everyone knows that this solution will not solve the problem. If you make NUL global it will override a NUL alias. NUL is not part of the interpreter. It's behavior is unpredictable. It's like using $mircexe:NULL. It may work. It may not. Depends on how the user has it installed. You leave the NUL object in and it WILL lead to future hardships down the road.

Consistency is key to scripting. Consistency of the language and how it performs in every situation. This goes against that.

If you are concerned about speed then don't use /filter for reading files. And speed is pretty irrelevant these days...

No /debug cannot use special devices :-) It is simply failing quietly in this case if it cannot open the filename.

While that would be the easiest solution, I would not be comfortable with allowing NUL device access to every single feature and routine in mIRC. There are many routines that explicitly need to fail if device access is attempted and the burden of that check, by design, is now centralized in the file handling routine.

Remember: in previous versions of mIRC, all routines had access to device names unless explicitly prevented. This was not safe and could have led to random freezes/crashes without you ever being aware of the cause. We now have the opposite and more cautious design: all routines do not have access to device names unless explicitly allowed.

I am happy to allow write access to the NUL device for specific features, such as /filter and /fopen. Alternatively, I can remove device name access completely, which is what I would prefer.

Fair enough. I incorrectly assumed that /filter would call the alias as a regular alias as opposed to what it apparently does which is to call the alias as an identifier.

I actually think this behavior is strange because /filter is not interpreting any returned value from the called alias.

It seems to me that there aren't really that many ways that nul is currently being used legitimately. It's really just being used to allow a script to use the secondary actions of a particular command without using the primary actions.

For example, /filter's primary purpose is to output a filtered list, but it happens that the $filtered identifier is a convenient way to count the number of lines that contain certain text. This can be done without using /filter, but it's not as convenient.

Would it be possible to just add a switch to /filter and /debug that allows there to be no output source?

Many people may not remember the bug where "/con/con" would make mIRC crash. It may not be an issue now, but at the same time, it seems to me that it should be completely unnecessary if a few switches are added to a couple commands to provide similar behavior.

I would rather see a -switch for outputting to NUL (or the equivalent of doing so, as far as a script is concerned) for /filter and /debug (not sure if NUL is useful for anything else?) Using NUL seems a bit kludgy.

It seems like it's not actually NUL that's useful, it's just the fact you can /filter to fill $filtered without actually outputting data, and with /debug you can use the -i switch to use a script to act on debug data without actually outputting it anywhere. If those features could be replicated in mIRC then there wouldn't be any need for access to the device.

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!