Zugg Software :: View topic - Problems using #READ (and %read()) on a file. [Solved]

Posted: Sat Feb 07, 2009 1:35 am

I have a text file which I placed in CMUD's execution folder. I can open the file (using #FILE) with no problem. However, when I try to read the file, I get a back a NULL. This happens when I assign the file to a numbers in the range 1-5. When I assign it to 6, for instance, the read will return a line of garbage.

Posted: Sat Feb 07, 2009 3:57 am

Are you using a file in slot six that was created by writing to a file in slots 6-10? Those slots use a special record-based file format (the help has more info) and if you open a plain-text file in those slots, you'll get garbage, yes.

Posted: Sat Feb 07, 2009 4:51 am

I opened it in slot 6 to prove to myself that the file could be read. I understand about the garbage. What I was trying to say was that if I open the file in slot 1, for instance, the #READ or %read() will retrieve nothing. I get a NULL back. It doesn't matter, whether, I specify a record number or not. I am supposing that the record markers are not to CMUD's liking, so the question is. What does a CMUD EOR marker looks like?
That would be one place to start looking for the problem. If CMUD's EOR matches the EOR from the file, then that's not the problem.

Posted: Sat Feb 07, 2009 5:08 am

Tell me exactly what it is you're doing, pressing, running or whatever to create this file, and then exactly what you're doing to make it not work when you try to read it. At the moment I have no idea if you created this file yourself, if you used slots 1-5 or 6-10, what sort of data you put in it (if any) and I have no idea how you're trying to get it back out. With so little information, I can't really help you.

Posted: Sat Feb 07, 2009 5:48 am

I didn't create the file. The file is a CSV file which I want to use to create a database. I wrote a script that opened the file in slot 1, and attempted to read it record by record, but it never reads anything. The first record has the column list, and the rest of the records have the data for the database file in the form <columndata1>,....,<columndataN> for each row. One row per record. The file was created by MySQL.

EDIT: A CSV file is a text file, so if you are not using it to populate a database there is nothing special about it.

Posted: Sat Feb 07, 2009 6:02 am

Okay, you definitely shouldn't be assigning it to slots 6-10 then. CMUD's format for those slots has nothing to do with CSV.

Beyond that, there's no reason why it should return null unless there's something strange about the file - like, say, it has lines ending in only LF or CR and CMUD expects both. Can you post the file somewhere?

Posted: Sat Feb 07, 2009 7:11 am

I'm reading a CSV file here just fine. As Fang mentioned, be sure each line ends in a CR and LF character (char 13 and char 10). That's the standard newline for Windows text files. You might try opening the file in some sort of editor that will show you any control codes in the file to see if there is any other problem with it. But CMUD is using CR/LF as the end-of-record line marker. If there is a NULL character (char 0) in the file, that will also cause trouble. But a standard CSV file written from Excel, for example, should work fine.

Posted: Sat Feb 07, 2009 4:32 pm

Posted: Sat Feb 07, 2009 7:46 pm

I loaded the CSV file into notepad++ and it shows that the EOL marker is CRLF. However, the following sample code just echoes NULLs.

Posted: Sun Feb 08, 2009 12:38 am

Can you PM one of us the files so we can try it.

Posted: Sun Feb 08, 2009 6:37 pm

The documentation for the#FILE command contains the following statement:

The filename given in name is restricted to the current directory containing CMUD.EXE and cannot refer to a EXE, HLP, or MUD file.

This is incorrect. The file must be in the directory that contains the session folders.

I discovered this when I found that CMUD had created a file (of 0 length) in said directory with the same name as the file that I used above. Evidently, if the file doesn't exist, CMUD creates one (which makes sense, if one wants to write to a new file. However, this is not documented).

The appended post by Jed is partly incorrect. He states that the file must be in the directory containing the default package, when in fact, it is the parent directory of the one containing the default package (i.e. The directory containing the Packages directory).
Of course, if one has everything in a single master directory (not recommended for Vista users if they use the default Program Files directory) then this problem won't appear.

Enchanter Joined: 09 Sep 2007 Posts: 605

Posted: Sun Feb 08, 2009 11:46 pm

Fixed.