fritzson@PRC.UNISYS.COM (Richard Fritzson) (03/02/88)
Does anyone have a workaround for the fact that CL:READ doesn't
translate a UNIX line-feed into a #NewLine when it is embedded in a string?
The problem with leaving them as line-feeds is that all FORMAT
statements which use the ~<NewLine> directive fail.
Our current workaround is using the UNIX "tr" command to replace the
linefeeds with carriage returns before we compile, but this is a drag.
-Rich Fritzson
Unisys - Paoli Research Center
P.O. Box 517
Paoli, PA 19301
(215) 648-7606
ARPA: fritzson@prc.unisys.com
UUCP: {sdcrdcf, psuvax1, cbmvax}!burdvax!fritzsonfritzson@PRC.UNISYS.COM (Richard Fritzson) (03/02/88)
As usual, asking the question out loud caused me to think of a new answer. If anyone else is suffering with the aforemention bug, ADVISE(\RSTRING2 AFTER (CL:NSUBSTITUTE #\NewLine #\LineFeed |VALUE)) will work. In some environments you will probably want to test some of the attributes of the stream you are reading from. If anyone has a better patch (one which won't slow things down as much as this one will), I'd be very glad to hear about it. -Rich Fritzson
Pavel.pa@XEROX.COM (03/02/88)
It sounds to me like the end-of-line translation parameters for your means of transferring the UNIX file to your own machine is wrong. The compiler should never be seeing those line-feeds. If you're using some sort of UNIX file server, there should be some way to set up the connection such that line-feeds are translated into carriage-returns automatically when the file is transferred. As far as I can tell from the documentation, this is the EOL property of the stream, which is supposed to be properly defaulted by the file device that makes connections to your server. It looks like you haven't set up the parameters for that device properly. Pavel
ziobro.henr@XEROX.COM (03/05/88)
No one mentioned which protocol is being used. If it is PUP then you can get proper EOL convention by NOT using the Leaf server. The FTP Server handled EOL correctly but the Unix Leaf Server only handles binary files, i.e. it botches text files. To make sure you read files correctly the OPENSTREAM must specify SEQUENTIAL access only. //Z\\ Jim Ziobro