It turns out that the retrlines method strips of EOL CRLF and \n. My solution was to create a new method in ftplib that doesn't do this. I'm assuming that there is a better OOP solution to this, e.g. some kind of subclassing, but do not have the expertise as yet to implement that. At any rate, just thought I'd post in case others encountered the same issue. Incidentally, though, I'm wondering about the slightly different transfer results. Specifically, when I use DOS, the file transfers like this --
string, string, string (hidden CRLF) string, string, string (hidden CRLF) ... but when I use Python in transfers like this -- string, string, string (hidden CRLF) string, string, string (hidden CRLF). If it's not obvious, the source file (sitting on a mainframe somewhere) is in comma-delimited format. As it is now, I've coded an Access application to automatically "import" the file, clean it for my purposes, and "export" it's contents appropriately etc. But for whatever reason the import wizard inserts a blank record for each CRLF. When I use DOS and get the format indicated above, this doesn't occur. Any ideas as to how I could resolve this? It's not a big deal as I can just have Access refuse to import blank lines. However, the general procedure does take longer to execute etc.... hawk -- http://mail.python.org/mailman/listinfo/python-list
