www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - std.file bug? std.regex bug?

reply "Simen kjaeraas" <simen.kjaras gmail.com> writes:
I have this weirdest bug. I'm extracting a list of files from a file,
using std.regex. Then, I try to open each of these, using
std.file.readText. This gives me this error:

std.file.FileException: In std\file.d(198), data file data: The
filename, directory name, or volume label syntax is incorrect.

Now, the funny thing is, the filename given (data) is wrong. The
filename extracted (and confirmed, by printing it) is data.ini. If I
hardcode the file name, no problem occurs.

So, printing the filename confirms that the regex works, and
hardcoding it confirms that readText works. Nothing else does
anything to the filename.

Does anyone have the slightest idea what might be wrong?

-- 
Simen
Jun 26 2010
parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
It could be that the string returned from the regex looks the same as the
hardcoded string but contains characters that don't show up when you print
it.
Does adding
assert(regexResult == expectedFilename);
throw?

"Simen kjaeraas" <simen.kjaras gmail.com> wrote in message 
news:op.vewf53itvxi10f biotronic-pc.lan...

I have this weirdest bug. I'm extracting a list of files from a file,
 using std.regex. Then, I try to open each of these, using
 std.file.readText. This gives me this error:

 std.file.FileException: In std\file.d(198), data file data: The
 filename, directory name, or volume label syntax is incorrect.

 Now, the funny thing is, the filename given (data) is wrong. The
 filename extracted (and confirmed, by printing it) is data.ini. If I
 hardcode the file name, no problem occurs.

 So, printing the filename confirms that the regex works, and
 hardcoding it confirms that readText works. Nothing else does
 anything to the filename.

 Does anyone have the slightest idea what might be wrong?

 -- 
 Simen
Jun 26 2010
parent reply "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Daniel Murphy <yebblies nospamgmail.com> wrote:


 It could be that the string returned from the regex looks the same as the
 hardcoded string but contains characters that don't show up when you  
 print
 it.
 Does adding
 assert(regexResult == expectedFilename);
 throw?


Not after I changed what was actually the problem - trailing spaces.
Still, the error I got gave absolutely no indication that that might be it.

-- 
Simen
Jun 26 2010
parent reply div0 <div0 users.sourceforge.net> writes:
On 26/06/2010 12:23, Simen kjaeraas wrote:

 Daniel Murphy <yebblies nospamgmail.com> wrote:


 It could be that the string returned from the regex looks the same as the
 hardcoded string but contains characters that don't show up when you
 print
 it.
 Does adding
 assert(regexResult == expectedFilename);
 throw?


 Not after I changed what was actually the problem - trailing spaces.
 Still, the error I got gave absolutely no indication that that might be it.


Yes it did. It told you exactly what was wrong.

The bit that says:

'The filename, directory name, or volume label syntax is incorrect.'

Its the error message from windows telling you that you got the file 
name wrong.

Trailing spaces are not allowed on windows, so it's not even tried to 
open a file, it's just told you that the file name syntax is wrong.

http://msdn.microsoft.com/en-us/library/aa365247(v=VS.85).aspx

Though perhaps the formatting of the exception text should be changed a 
bit to make it clear which bit is the system error part.

If it bothers you enough, it's worth filing a bug report:

http://d.puremagic.com/issues/

Andrei and the rest of the guys are pretty quick at knocking off these 
issues.

-- 
My enormous talent is exceeded only by my outrageous laziness.
http://www.ssTk.co.uk
Jun 26 2010
parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
div0 <div0 users.sourceforge.net> wrote:


 Not after I changed what was actually the problem - trailing spaces.
 Still, the error I got gave absolutely no indication that that might be  
 it.


 Yes it did. It told you exactly what was wrong.


Awright, I agree I overstated things there. My point however, was that the
error message ate the file extension, making things harder to understand.

The exact symbol that was appended, was \r. The reason it seemed to eat
the extension was that the extension was the first thing on the new line,
and thus the carriage return overwrote everything from the beginning of
the line. I'm not sure if the error handler should take such symbols into
account.

-- 
Simen
Jun 26 2010