mIRC Home    About    Download    Register    News    Help

Print Thread
Page 1 of 2 1 2
mIRC 7.0 and NUL ("bit bucket") #220120 05/04/10 09:22 PM
Joined: Nov 2006
Posts: 1,559
H
Horstl Offline OP
Hoopy frood
OP Offline
Hoopy frood
H
Joined: Nov 2006
Posts: 1,559
Worked up to v6.35, now throws an error (unable to open file '<mircinidir>\nul'):
Code:
alias filtertonul {
  filter -ff $qt($mircini) nul n0=*
  echo -ag filtered: $filtered 
}
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 smile

Last edited by Horstl; 05/04/10 09:31 PM.
Re: mIRC 7.0 and NUL ("bit bucket") [Re: Horstl] #220138 06/04/10 01:34 AM
Joined: Mar 2010
Posts: 57
W
Wiz126 Offline
Babel fish
Offline
Babel fish
W
Joined: Mar 2010
Posts: 57
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

Last edited by Wiz126; 06/04/10 01:46 AM.
Re: mIRC 7.0 and NUL ("bit bucket") [Re: Wiz126] #220139 06/04/10 01:57 AM
Joined: Nov 2006
Posts: 1,559
H
Horstl Offline OP
Hoopy frood
OP Offline
Hoopy frood
H
Joined: Nov 2006
Posts: 1,559
Thanks, I already know what "nul" is. smile 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. wink

Re: mIRC 7.0 and NUL ("bit bucket") [Re: Horstl] #220269 09/04/10 12:29 PM
Joined: Dec 2002
Posts: 4,563
Khaled Offline
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 4,563
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.

Re: mIRC 7.0 and NUL ("bit bucket") [Re: Khaled] #220276 09/04/10 05:22 PM
Joined: Nov 2006
Posts: 1,559
H
Horstl Offline OP
Hoopy frood
OP Offline
Hoopy frood
H
Joined: Nov 2006
Posts: 1,559
Pity to hear that frown
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?

Re: mIRC 7.0 and NUL ("bit bucket") [Re: Horstl] #220277 09/04/10 08:16 PM
Joined: Oct 2004
Posts: 8,327
Riamus2 Offline
Hoopy frood
Offline
Hoopy frood
Joined: Oct 2004
Posts: 8,327
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?


Invision Support
#Invision on irc.irchighway.net
Re: mIRC 7.0 and NUL ("bit bucket") [Re: Riamus2] #220287 10/04/10 03:08 AM
Joined: Oct 2003
Posts: 3,918
A
argv0 Offline
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
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.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Re: mIRC 7.0 and NUL ("bit bucket") [Re: Riamus2] #220295 10/04/10 09:09 AM
Joined: Jan 2004
Posts: 162
R
RRX Offline
Vogon poet
Offline
Vogon poet
R
Joined: Jan 2004
Posts: 162
I use for these situations filter -fk somefile $ somematchtext.

Re: mIRC 7.0 and NUL ("bit bucket") [Re: Horstl] #220296 10/04/10 09:39 AM
Joined: Dec 2002
Posts: 4,563
Khaled Offline
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 4,563
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.

Re: mIRC 7.0 and NUL ("bit bucket") [Re: Khaled] #220302 10/04/10 02:10 PM
Joined: Dec 2002
Posts: 339
D
drum Offline
Fjord artisan
Offline
Fjord artisan
D
Joined: Dec 2002
Posts: 339
Originally Posted By: Khaled
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?

Code:
/filter -fk $qt($mircini) return n0=*

Re: mIRC 7.0 and NUL ("bit bucket") [Re: drum] #220304 10/04/10 03:43 PM
Joined: Nov 2006
Posts: 1,559
H
Horstl Offline OP
Hoopy frood
OP Offline
Hoopy frood
H
Joined: Nov 2006
Posts: 1,559
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! smile

Re: mIRC 7.0 and NUL ("bit bucket") [Re: Khaled] #220310 10/04/10 06:33 PM
Joined: Mar 2010
Posts: 57
W
Wiz126 Offline
Babel fish
Offline
Babel fish
W
Joined: Mar 2010
Posts: 57
Originally Posted By: Khaled
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.



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.

Code:
//debug -i NUL processRaw 

Alias processRaw {
  ...
}

Last edited by Wiz126; 10/04/10 06:52 PM.
Re: mIRC 7.0 and NUL ("bit bucket") [Re: Wiz126] #220324 11/04/10 04:26 AM
Joined: Oct 2003
Posts: 3,918
A
argv0 Offline
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
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.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Re: mIRC 7.0 and NUL ("bit bucket") [Re: drum] #220326 11/04/10 06:13 AM
Joined: Jan 2004
Posts: 162
R
RRX Offline
Vogon poet
Offline
Vogon poet
R
Joined: Jan 2004
Posts: 162
Originally Posted By: drum
Originally Posted By: Khaled
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?

Code:
/filter -fk $qt($mircini) return n0=*

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.

Re: mIRC 7.0 and NUL ("bit bucket") [Re: Horstl] #220327 11/04/10 06:29 AM
Joined: Apr 2003
Posts: 342
M
MeStinkBAD Offline
Fjord artisan
Offline
Fjord artisan
M
Joined: Apr 2003
Posts: 342
Originally Posted By: Horstl
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.


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...


Beware of MeStinkBAD! He knows more than he actually does!
Re: mIRC 7.0 and NUL ("bit bucket") [Re: Wiz126] #220328 11/04/10 09:02 AM
Joined: Dec 2002
Posts: 4,563
Khaled Offline
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 4,563
No /debug cannot use special devices :-) It is simply failing quietly in this case if it cannot open the filename.

Re: mIRC 7.0 and NUL ("bit bucket") [Re: argv0] #220329 11/04/10 09:33 AM
Joined: Dec 2002
Posts: 4,563
Khaled Offline
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 4,563
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.

Re: mIRC 7.0 and NUL ("bit bucket") [Re: RRX] #220338 11/04/10 01:06 PM
Joined: Dec 2002
Posts: 339
D
drum Offline
Fjord artisan
Offline
Fjord artisan
D
Joined: Dec 2002
Posts: 339
Originally Posted By: RRX
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.


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.

Re: mIRC 7.0 and NUL ("bit bucket") [Re: Khaled] #220341 11/04/10 01:34 PM
Joined: Dec 2002
Posts: 339
D
drum Offline
Fjord artisan
Offline
Fjord artisan
D
Joined: Dec 2002
Posts: 339
Originally Posted By: Khaled
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.


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.

Re: mIRC 7.0 and NUL ("bit bucket") [Re: Khaled] #220344 11/04/10 02:17 PM
Joined: Sep 2005
Posts: 2,876
H
hixxy Offline
Hoopy frood
Offline
Hoopy frood
H
Joined: Sep 2005
Posts: 2,876
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.

Page 1 of 2 1 2