Unix format text file in VFP 3

[linousa]

I was getting windows format text files before and they worked just fine with FOPEN(), but apparently, my resource start providing unix format text files and our app would give me an error message. I can manually copy and paste those text files in win editors and they will work fine after, and even write small batch file to make it automatic, but these are not solutions- these are just work around! So my question- is there any way to solve it in VFP normally?

 

[Mike Lewis]

Can you open the file with FILETOSTR() - (I would think you can, but you would have to try it and see)?

If so, you have a couple of choices. You should be able to use ALINES() to unpack the individual lines of text. Or you can use STRTRAN() to convert the line endings.

If you need any more detailed help on those options, just yell.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Dan Freeman]

What error message were you getting?

Text is text. That's why it's the lingua franca for data moving between platforms. Most likely what you encountered was *nix using just LF at end of line instead of CRLF, but that's speculating.

 

[Olaf Doschke]

I think it's not FOPEN failing, you can open the files, can't you, it's FGETS gets more than one line at a time. You can't reuse code using FGETS, as that needs carriage returns. It disregards linefeeds and unix files only have line feeds.

You can emulate FGETS by reading with FGET, especially easy if lines have a fixed length. If not, read as much blocks of N bytes, until you encounter a line feed and unlike fgets don't disregard it. Concatenate readed blocks up to the first line feed, that's a line then, store the rest after the line feed as the start of the next line.

Bye, Olaf.

 

[linousa]

Thank you everyone for your help, FOPEN() works just fine with any format, FSEEK() works differently in these formats, bc number characters in lines and I had it my "data homogeneity" block:

* Seek to end of file to determine the number of bytes in the file
	nSize =  Fseek(gnDataFile, 0, 2) && Move pointer to EOF
	= Fseek(gnDataFile,nSize-101) && Go to beggining of the last line
* Checks if this file complete
	cString = Fgets(gnDataFile,101)
 	If Substr(cString,1,2)!='CT' && 'CT' is always the same(last line fist two)
 	    Wait Window "This is not a complete file!"
	    =Fclose(gnDataFile)
	Endif

 

[linousa]

Before there were 102 characters in the line and all I had to change 102->101, bc as danfreeman said win->unix (CRLF->LF) Thank you very much!

PROBLEM SOLVED!​

 

[Dan Freeman]

Glad you've got it working, but I can't help wondering if the combination of FILETOSTR() and ALINES() wouldn't make this a lot simpler (and end-of-line agnostic) for you.

But what matters is it's working.

 

[Olaf Doschke]

Indeed reading up to LF or CR or CRLF will always give full lines.

But if it's a defined format and the rest of the code works with fixed column width that, it won't help much to make the code aware for the different end of line marks.

Assuming you'll get files in unix and windows format in the future and the net data is in the first 100 bytes of each line anyway, I'd change the code to read in 102 bytes from the file start and then analyse the last two bytes to be 1. CR, 2. LF or 3. CRLF. In Mac you'll have CR only, for example. So, if the last two bytes are CRLF you know you have windows. If the last byte isn't LF, but the 101th byte is either CR or LF you have a linux or mac format.

Then fseek to the start and read in lines with either 101 bytes per line (linux/unix/mac/beos) or 102 bytes per line (Windows). Remove either 1 or 2 bytes off the end and process the net bytes the way you always do.

Bye, Olaf.

 

[Olaf Doschke]

Oh, and if the line widths are indeed fixed, it'll be better to read with FREAD than with FGETS. Your code working with the fix of 102->101 indicates this is the case, because if there were lines shorter you previously got right by FGETS, which stops at any CR, you'd have a problem without CRs, no matter if you'd use 102 or 101 max length, the files have fixed width lines, then code should perhaps indicate that better by reading fixed length blocks of bytes, too. FGETS let's any developer assume line lengths may vary and are limited with up to 101 bytes.

Bye, Olaf.