Re: [PATCH] Further lies in the File::Basename docs
in which CTYPE is [A-Z] not uppercase for [a-z], and [a-z] not lowercase for [A-Z] ? http://msdn.microsoft.com/netframework/default.aspx?pull=/library/en-us/ dndotnet/html/stringsinnet20.asp#stringsinnet20_topic5
RE: [PATCH] Further lies in the File::Basename docs
Michael G Schwern wrote: Yitzak outlined a way to determine case-sensitivity in a read-only fashion. It basically boils down to: 1. Find a file or directory with [A-Za-z] in it. 2. Change the case of a few of those letters. 3. Check to see if it exists. Hmmm, with some intelligent check to make sure that A.a and a.a aren't both there as different files, I guess? Otherwise a case sensitive directory would be misdiagnosed as insensitive. I suppose if the file found in step 1 is A.a, a glob could be done on [Aa].a and the result count checked... -- Mike Giroux rmgiroux (at) acm (point) org
Re: [PATCH] Further lies in the File::Basename docs
Glenn Linderman [EMAIL PROTECTED] writes: 5. verify that an entry with that modification doesn't already exist attempt to stat the entry with the modified name, if it works as with the unmodified name, then the file system is case insensitive. Or someone created it since you verified it wasn't there.
Re: [PATCH] Further lies in the File::Basename docs
Michael G Schwern [EMAIL PROTECTED] writes: On Fri, Jul 08, 2005 at 12:12:44AM +0200, Abigail wrote: That's not going to work on a file system that's mounted read-only. Yitzak outlined a way to determine case-sensitivity in a read-only fashion. It basically boils down to: 1. Find a file or directory with [A-Za-z] in it. 2. Change the case of a few of those letters. In which CTYPE do you change the case ;-) 3. Check to see if it exists.
Re: [PATCH] Further lies in the File::Basename docs
Glenn Linderman [EMAIL PROTECTED] writes: On approximately 7/8/2005 12:22 PM, came the following characters from the keyboard of Nick Ing-Simmons: Glenn Linderman [EMAIL PROTECTED] writes: 5. verify that an entry with that modification doesn't already exist attempt to stat the entry with the modified name, if it works as with the unmodified name, then the file system is case insensitive. Or someone created it since you verified it wasn't there. Yes, and you could reverify that it still isn't there, and then of course, that could mean that someone deleted it since you discovered it was there. And if the someone else was perl doing a write style probe that becomes both cases are quite likely if OS yields CPU on system calls. Thanks for pointing out a statistical weakness in the algorithm.
Re: [PATCH] Further lies in the File::Basename docs
On Fri, Jul 08, 2005 at 08:57:37PM +0100, Nick Ing-Simmons wrote: Yes, and you could reverify that it still isn't there, and then of course, that could mean that someone deleted it since you discovered it was there. And if the someone else was perl doing a write style probe that becomes both cases are quite likely if OS yields CPU on system calls. Write style probes would happen in their own subdirectory to minimize the possibilities of interference. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern 'All anyone gets in a mirror is themselves,' she said. 'But what you gets in a good gumbo is everything.' -- Witches Abroad by Terry Prachett
Re: [PATCH] Further lies in the File::Basename docs
On Fri, Jul 08, 2005 at 02:03:33PM -0700, Glenn Linderman wrote: And if the someone else was perl doing a write style probe that becomes both cases are quite likely if OS yields CPU on system calls. No, I disagree there. A write style probe should create a new name, unequal to any other existing name, including the timestamp and a random number in the name to make uniqueness highly probable, stat the result, alter the name by case of one or more alphabetic characters, stat that, and if the results are the same, then conclude that it is a case insensitive file name. The chances of picking at random the same name that a read style probe would pick are extremely unlikely. And why would perl be doing both styles of probes in the same directory at the same time anyway? Multiple processes running the same program doing the same thing. Only happens very, very rarely, like say in a CGI program. :P -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Don't try the paranormal until you know what's normal. -- Lords and Ladies by Terry Prachett
Re: [PATCH] Further lies in the File::Basename docs
On Fri, Jul 08, 2005 at 02:46:37PM -0700, Glenn Linderman wrote: And why would perl be doing both styles of probes in the same directory at the same time anyway? Multiple processes running the same program doing the same thing. Only happens very, very rarely, like say in a CGI program. :P Well, now, multiple processes running the same program doing the same thing wouldn't qualify as perl doing both styles of probes in the same directory at the same time... because if it uses a read probe to determine case sensitivity, then it doesn't need to do a write probe to determine case sensitivity. And while even those probes shouldn't use the same sorts of names, other probes for other information, would surely use even different names. Yes, CGI programs are prolific, and do the same thing repeatedly for the same and different users. And what did you say about caching results? It was really more your oh, that could never happen style response of two processes doing different things in the same directory without being aware of each other. Anyhow, this is all moot as any write probes will happen in a unique, temporary subdirectory. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Ahh email, my old friend. Do you know that revenge is a dish that is best served cold? And it is very cold on the Internet!
Re: [PATCH] Further lies in the File::Basename docs
On Wed, Jul 06, 2005 at 11:12:34PM -0700, Glenn Linderman wrote: Yep, there is more to a file system than case sensitivity. But I'm hoping that you probe as needed, and cache results for future requests, rather than probing for all this info including if it is never used... and walk softly, perturbing as little as possible to obtain the information desired. The plan goes something like this: * Offer to do a full probe at installation time (when we will likely be root). Query the user about things like mount points. Cache the results. * When cached results aren't available (or have been flushed) each accessor will do its probe on demand. An optimization might be to combine multiple similar probes together as one. * If the user wants, they can just say a given mount point is of a given known file system type thus avoiding all probing. * The administrator can at any time ask for a reprobe like the one done at installation time should the mount points change. You're right, though. If I can make the probe read-only so much the better. Case-sensitivity is really the only one I can think of how to do read-only. Fortunately, its also by far the most common concern. # Is this determined by the OS or the file system? File system. Win32 supports FAT and NTFS, only the latter supports junction points and reparse points. $fs-can_symlink_files; $fs-can_hardlink_files; $fs-can_symlink_dirs; $fs-can_hardlink_dirs; But does Perl translate them into symlinks and hard links? If it doesn't then we'll never see it. Which is, in the end, all we care about. Quite an ambitious list. I can't imagine that you can probe all of that stuff in an OS independent manner. But I'm willing to watch, and be impressed. I've done most of it already here and there. The real hold up is structuring the probing system so its extensable and doesn't wind up looking like Configure. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Don't try the paranormal until you know what's normal. -- Lords and Ladies by Terry Prachett
Re: [PATCH] Further lies in the File::Basename docs
On 7/7/05, Michael G Schwern [EMAIL PROTECTED] wrote: Its the most accurate with the least proliferation of platform-specific hacks. Is the core really the place for probing ? I don't expect fs probing code to be sufficiently stable in the near future to go in the core. Portability is always harder than you think.
Re: [PATCH] Further lies in the File::Basename docs
On 7/7/05, Michael G Schwern [EMAIL PROTECTED] wrote: The plan goes something like this: * Offer to do a full probe at installation time (when we will likely be root). Query the user about things like mount points. Cache the results. In those days of package management software, most perls and perl modules aren't configured / compiled on the same system they'll be installed on.
Re: [PATCH] Further lies in the File::Basename docs
On Thu, Jul 07, 2005 at 10:13:01AM +0200, Rafael Garcia-Suarez wrote: On 7/7/05, Michael G Schwern [EMAIL PROTECTED] wrote: Its the most accurate with the least proliferation of platform-specific hacks. Is the core really the place for probing ? As always it goes on CPAN first. Worry about core issues later. I don't expect fs probing code to be sufficiently stable in the near future to go in the core. Portability is always harder than you think. You're telling me?! *looks at MakeMaker* -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Ahh email, my old friend. Do you know that revenge is a dish that is best served cold? And it is very cold on the Internet!
Re: [PATCH] Further lies in the File::Basename docs
On Thu, Jul 07, 2005 at 10:18:13AM +0200, Rafael Garcia-Suarez wrote: On 7/7/05, Michael G Schwern [EMAIL PROTECTED] wrote: The plan goes something like this: * Offer to do a full probe at installation time (when we will likely be root). Query the user about things like mount points. Cache the results. In those days of package management software, most perls and perl modules aren't configured / compiled on the same system they'll be installed on. This is up to the package manager to deal with. A simple solution is to have a post-install script which runs the initial probe. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Don't try the paranormal until you know what's normal. -- Lords and Ladies by Terry Prachett
Re: [PATCH] Further lies in the File::Basename docs
Michael G Schwern wrote:
Sometimes you want to write a patch just for the subject line. :)
Thanks - applied as change 25089.
A couple of minor POD changes again (another podchecker nit, and C
around function names, for now at least) plus a fix for a serious bug
which completely screwed *everything* in Win32-land: the assignment to
@Ignore_Case and @Types was carried out too late - long after the
initial call to fileparse_set_fstype()! I've put the assignment in a
BEGIN { } block to fix it, and threw the fileparse_set_fstype() function
itself into the same scope since it is the only thing requiring access
to those lexicals.
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are
confidential and intended for the addressee(s) only. If you have received this
message in error or there are any problems, please notify the sender
immediately. The unauthorized use, disclosure, copying or alteration of this
message is strictly forbidden. Note that any views or opinions presented in
this email are solely those of the author and do not necessarily represent
those of Radan Computational Ltd. The recipient(s) of this message should
check it and any attached files for viruses: Radan Computational will accept no
liability for any damage caused by any virus transmitted by this email.
Re: [PATCH] Further lies in the File::Basename docs
On Wed, Jul 06, 2005 at 03:46:02PM -1000, Joshua Hoblitt wrote: On Wed, Jul 06, 2005 at 06:39:38PM -0700, Glenn Linderman wrote: However, also note that the sensitivity characteristic of any particular directory cannot be intuited from the sensitivity characteristic of any other directory, due to softlinks pointing to other filesystems... unless you confirm that both are one the same (type of) filesystem, which gets you back to platform specific code again, I think. Does it? I don't know of any platforms on which symlinks can't be detected. It doesn't matter whether symlinks are detected. Assumptions go pear shaped if I mount a case insensitive file system somewhere in a subdirectory of a case sensitive file system (or vice versa) You really can't tell what's going on in any other directory, based on the one you're in. I'm wondering if you can't even tell what's going on in one directory, if that directory is a logical union of several others on differing filesystems. Then again, I've not met these on any system I use. Nicholas Clark
Re: [PATCH] Further lies in the File::Basename docs
On Thu, Jul 07, 2005 at 04:02:07PM +0100, Nicholas Clark wrote: It doesn't matter whether symlinks are detected. Assumptions go pear shaped if I mount a case insensitive file system somewhere in a subdirectory of a case sensitive file system (or vice versa) That why we ask for the mount points. Things can potentially go wrong when File::System::Spec is used to just probe the cwd without knowing where the mount points are. The user is free to assume whatever they want from the characteristics of the cwd, and most of the time its probably perfectly correct, but File::System::Spec does not make the assumption. When I can see this going wrong in the field is if probing is done very high up in the directory tree like in / or /tmp. However, given that currently there are NO utilities for probing file system characteristics and that we blindly assume them based on $^O this is nothing but a step up. You really can't tell what's going on in any other directory, based on the one you're in. I'm wondering if you can't even tell what's going on in one directory, if that directory is a logical union of several others on differing filesystems. Then again, I've not met these on any system I use. Please, don't give me nightmares. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Just call me 'Moron Sugar'. http://www.somethingpositive.net/sp05182002.shtml
Re: [PATCH] Further lies in the File::Basename docs
On Thu, Jul 07, 2005 at 10:25:36AM -0700, Glenn Linderman wrote: Yes, provision for some level of change of the cached information is good, even necessary. Under what conditions would flushing take place? Ever automatically? When a system is reconfigured, that is when an additional probe would be needed. It'll be manual. About the only way I can see making it automatic is to have something which can automatically determine the current mount points and file types (say by using `df -T`) and recognize that they have changed. But this gets system specific. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Don't try the paranormal until you know what's normal. -- Lords and Ladies by Terry Prachett
Re: [PATCH] Further lies in the File::Basename docs
On Wed, Jul 06, 2005 at 11:11:19AM -1000, Joshua Hoblitt wrote: On Wed, Jul 06, 2005 at 09:40:11AM -0700, Michael G Schwern wrote: On Wed, Jul 06, 2005 at 11:29:21AM -0500, Andy Lester wrote: On Wed, Jul 06, 2005 at 09:22:32AM -0700, Michael G Schwern ([EMAIL PROTECTED]) wrote: * Simplify the what's case-insensitive docs. Its just all non-Unix. What about Mac OS X running HFS? Or Linux running FAT32? Or OS X running UFS (which is case sensitive)? The whole idea is basically doomed because we assume the underlying file system type based on the operating system. But we make this assumption all over the place in the Perl core and File::Basename is not the place to start fixing it. Instead of trying to determine which filesystem your on (is there any reasonable way of evening doing that?) why not just test for case sensitivity when the module is loaded with a BEGIN block? Granted this is ugly, and granted you would likely only be able to test the file system that a dir created by File::Temp::tempdir() lives on, but it should be fairly portable. That's not going to work on a file system that's mounted read-only. I'd say that for systems that have a /proc/mounts file that lists the file type, the lookup table based on OS should be replaced by a lookup table based on filesystem. Abigail pgp8jUYV4oXwa.pgp Description: PGP signature
Re: [PATCH] Further lies in the File::Basename docs
On Fri, Jul 08, 2005 at 12:12:44AM +0200, Abigail wrote: That's not going to work on a file system that's mounted read-only. Yitzak outlined a way to determine case-sensitivity in a read-only fashion. It basically boils down to: 1. Find a file or directory with [A-Za-z] in it. 2. Change the case of a few of those letters. 3. Check to see if it exists. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Ahh email, my old friend. Do you know that revenge is a dish that is best served cold? And it is very cold on the Internet!
Re: [PATCH] Further lies in the File::Basename docs
On Wed, Jul 06, 2005 at 09:22:32AM -0700, Michael G Schwern ([EMAIL PROTECTED]) wrote: * Simplify the what's case-insensitive docs. Its just all non-Unix. What about Mac OS X running HFS? -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: [PATCH] Further lies in the File::Basename docs
On Wed, Jul 06, 2005 at 11:29:21AM -0500, Andy Lester wrote: On Wed, Jul 06, 2005 at 09:22:32AM -0700, Michael G Schwern ([EMAIL PROTECTED]) wrote: * Simplify the what's case-insensitive docs. Its just all non-Unix. What about Mac OS X running HFS? Or Linux running FAT32? Or OS X running UFS (which is case sensitive)? The whole idea is basically doomed because we assume the underlying file system type based on the operating system. But we make this assumption all over the place in the Perl core and File::Basename is not the place to start fixing it. Should OS X be considered case-insensitive because its usually running HFS+? *shrug* Probably. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern You are wicked and wrong to have broken inside and peeked at the implementation and then relied upon it. -- tchrist in [EMAIL PROTECTED]
Re: [PATCH] Further lies in the File::Basename docs
On Wed, Jul 06, 2005 at 11:11:19AM -1000, Joshua Hoblitt wrote: Instead of trying to determine which filesystem your on (is there any reasonable way of evening doing that?) why not just test for case sensitivity when the module is loaded with a BEGIN block? Granted this is ugly, and granted you would likely only be able to test the file system that a dir created by File::Temp::tempdir() lives on, but it should be fairly portable. That's the general idea. In fact I've just cracked open my old File::System::Spec idea to do just that sort of probing. However, this is outside the scope of File::Basename. Fixing the operating system == file system assumption piecemeal would just cause more problems. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Reality is that which, when you stop believing in it, doesn't go away. -- Phillip K. Dick
Re: [PATCH] Further lies in the File::Basename docs
On Wed, Jul 06, 2005 at 01:49:38PM -1000, Joshua Hoblitt wrote: File::System::Spec::Win32 - uses Win32::FsType() The 1st fall-back is the method I outlined of probing with tempdir() and the 2nd fall-back (and last resort) is a lookup table based on the os name ala File::Basename. I disagree. I believe the thing to do is probe. It provides the most accurate and timely information. It avoids having to write per operating system ways to figure out the file systems. It does not rely on external functions or files. It always works with future and unknown file systems. It shows how Perl interacts with the file system as opposed to how it theoretically should act. Its the most accurate with the least proliferation of platform-specific hacks. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Just call me 'Moron Sugar'. http://www.somethingpositive.net/sp05182002.shtml
Re: [PATCH] Further lies in the File::Basename docs
On Wed, Jul 06, 2005 at 09:40:11AM -0700, Michael G Schwern wrote: On Wed, Jul 06, 2005 at 11:29:21AM -0500, Andy Lester wrote: On Wed, Jul 06, 2005 at 09:22:32AM -0700, Michael G Schwern ([EMAIL PROTECTED]) wrote: * Simplify the what's case-insensitive docs. Its just all non-Unix. What about Mac OS X running HFS? Or Linux running FAT32? Or OS X running UFS (which is case sensitive)? The whole idea is basically doomed because we assume the underlying file system type based on the operating system. But we make this assumption all over the place in the Perl core and File::Basename is not the place to start fixing it. Instead of trying to determine which filesystem your on (is there any reasonable way of evening doing that?) why not just test for case sensitivity when the module is loaded with a BEGIN block? Granted this is ugly, and granted you would likely only be able to test the file system that a dir created by File::Temp::tempdir() lives on, but it should be fairly portable. -J -- pgpw4NWp6r0Bz.pgp Description: PGP signature
Re: [PATCH] Further lies in the File::Basename docs
On Wed, Jul 06, 2005 at 02:21:36PM -0700, Michael G Schwern wrote: On Wed, Jul 06, 2005 at 11:11:19AM -1000, Joshua Hoblitt wrote: Instead of trying to determine which filesystem your on (is there any reasonable way of evening doing that?) why not just test for case sensitivity when the module is loaded with a BEGIN block? Granted this is ugly, and granted you would likely only be able to test the file system that a dir created by File::Temp::tempdir() lives on, but it should be fairly portable. That's the general idea. In fact I've just cracked open my old File::System::Spec idea to do just that sort of probing. Starting over doesn't sound like all that bad of an idea. Something like: File::System::Spec::Solaris - parses /etc/mmntab File::System::Spec::Linux - parses /etc/mtab or /proc/mounts File::System::Spec::Win32 - uses Win32::FsType() . . The 1st fall-back is the method I outlined of probing with tempdir() and the 2nd fall-back (and last resort) is a lookup table based on the os name ala File::Basename. However, this is outside the scope of File::Basename. Fixing the operating system == file system assumption piecemeal would just cause more problems. Good point. -J -- pgp0KFgYiMfZ8.pgp Description: PGP signature
Re: [PATCH] Further lies in the File::Basename docs
On Wed, Jul 06, 2005 at 05:23:11PM -0700, Michael G Schwern wrote: On Wed, Jul 06, 2005 at 01:49:38PM -1000, Joshua Hoblitt wrote: File::System::Spec::Win32 - uses Win32::FsType() The 1st fall-back is the method I outlined of probing with tempdir() and the 2nd fall-back (and last resort) is a lookup table based on the os name ala File::Basename. I disagree. I believe the thing to do is probe. It provides the most accurate and timely information. It avoids having to write per operating system ways to figure out the file systems. It does not rely on external functions or files. It always works with future and unknown file systems. It shows how Perl interacts with the file system as opposed to how it theoretically should act. Unfortunately, 'just probing' will only work if /tmp (or wherever) is the same filesystem (and potently, has the same mount flags) as the path that you care about. That is barely an improvement over the assumptions made by File::Basename. Its the most accurate with the least proliferation of platform-specific hacks. If it doesn't give you a deterministic answer does it really solve the issue? How is this a compelling upgrade to File::Basename? -J -- pgpvqcNAeedAW.pgp Description: PGP signature
Re: [PATCH] Further lies in the File::Basename docs
On Wed, Jul 06, 2005 at 06:25:29PM -0700, Glenn Linderman wrote: Yes, I agree probing is a good idea. I would assume that you would do read-only probing, if possible. A sequence like 1. read the given directory. 2. choose an entry containing at least one character in [a-zA-Z]. 3. attempt to stat the entry with the unmodified name, return to step 2. 4. modify the case of at least one character in [a-zA-Z]. 5. verify that an entry with that modification doesn't already exist attempt to stat the entry with the modified name, if it works as with the unmodified name, then the file system is case insensitive. 6. If there are no entries exist in the given directory, try creating a file with a name containing at least one character in [a-zA-Z]. Perform steps 4 5, and delete the entry. 7. if a file cannot be created, and none exist, it is not clear that you care if the file system is case insensitive or not! would avoid creating new entries much of the time, and would work on read-only filesystems as well as read-write filesystems. That's pretty clever but I would suggest a extra step. 5.5. If no entries exist in the given directory and the directory's name has at least one character in [a-Z], try steps 4 5 on the directory itself. I'm not sure that I like #6. I generally dislike the idea of [potentially] 'littering' test files out side of a tempdir. -J -- pgpdYqwYMGR1G.pgp Description: PGP signature
Re: [PATCH] Further lies in the File::Basename docs
On Wed, Jul 06, 2005 at 06:39:38PM -0700, Glenn Linderman wrote: However, also note that the sensitivity characteristic of any particular directory cannot be intuited from the sensitivity characteristic of any other directory, due to softlinks pointing to other filesystems... unless you confirm that both are one the same (type of) filesystem, which gets you back to platform specific code again, I think. Does it? I don't know of any platforms on which symlinks can't be detected. -J -- pgpYvbTu2ecO5.pgp Description: PGP signature
Re: [PATCH] Further lies in the File::Basename docs
On Wed, Jul 06, 2005 at 06:25:29PM -0700, Glenn Linderman wrote: Yes, I agree probing is a good idea. I would assume that you would do read-only probing, if possible. This really only works for a very limited set of things you want to probe about a file system and assuming everything's all in place as needed. I'm being a little bit more ambicious based on problems I've encountered porting MakeMaker and bits in perlport. Here's the preliminary list of methods. $fs-mount_point; $fs-type; $fs-is_case_sensitive; $fs-is_case_preserving; $fs-special_characters; $fx-max_path_length; $fs-max_filename_length; $fs-max_directory_depth; $fs-max_filesize; # Is this determined by the OS or the file system? $fs-can_symlink_files; $fs-can_hardlink_files; $fs-can_symlink_dirs; $fs-can_hardlink_dirs; $fs-is_dot_special; # For network filesystems $fs-time_drift; $fs-create_time_accuracy; $fs-mod_time_accuracy; $fs-access_time_accuracy; $fs-has_file_mod_time; $fs-has_file_create_time; $fs-has_file_access_time; # ie. VMS/ODS5 $fs-is_versioning; # locking issues? Is that Filesystem or OS? $fs-has_flock; # can I figure this out? $fs-block_size; $fs-has_sparse_files; -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Just call me 'Moron Sugar'. http://www.somethingpositive.net/sp05182002.shtml
Re: [PATCH] Further lies in the File::Basename docs
On Wed, Jul 06, 2005 at 03:33:14PM -1000, Joshua Hoblitt wrote: Unfortunately, 'just probing' will only work if /tmp (or wherever) is the same filesystem (and potently, has the same mount flags) as the path that you care about. That is barely an improvement over the assumptions made by File::Basename. Who says we have to probe in /tmp? It does, however, mean we need write permission to a directory in each mount point. If we don't have write perms or if its a read-only mount or if the user just doesn't want us to probe then you fall back to platform specific probes to get the file system types (such as df -T) and rely on pre-built specifications. Don't worry, I have plans. ZimOh, such plans they are!/Zim *hand rubbing* *maniacal laughter* *crazy robot* -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Ahh email, my old friend. Do you know that revenge is a dish that is best served cold? And it is very cold on the Internet!
