On 2012-12-31 15:54, Brian Schenkenberger, VAXman- wrote: Johnny Billquist <bqt at softjar.se> writes: On 2012-12-31 14:59, Brian Schenkenberger, VAXman- wrote: Johnny Billquist <bqt at softjar.se> writes: LEGATO's INFO.TXT have real yucky file attributes and a real yucky file format. :-) (What on earth was used to produce it???) Stream_CR typically surfaces with files coming from WEENDOZE. Ah. Yes, that would be a possible, source, I guess. But I find Stream_CR a but surprising. Maybe I'm just too ignorant of VMS formats here. But isn't there a plain Stream as well (which also exists in RSX), in which records are terminated by CR+LF, and which is what I would expect a Windows machine to produce... VMS file formats: FIX ........ Fixed Record Size; Length in MRS VAR ........ Variable; Length embedded in record VFC ........ Variable Format Control; Length and Format embedded in record Stream ..... Stream; Length from scan for <CR><LF> Stream_LF .. Stream; Length from scan for <LF> Stream_CR .. Stream; Length from scan for <CR> UDF ........ Undefinded. Basically a superset of that I have in RSX, yes. The ones "missing" are Stream_LF and Stream_CR. Directory LEGATO::SYS$SPECIFIC:[FAL$SERVER] 31-DEC-12 13:59:07 INFO.TXT;1 Size: 8./35. Created: 08-JUL-10 10:54:52 Owner: [000376,000373] Revised: 27-DEC-12 19:24:34(6.) Expires: <none_specified> File protection: System:RE, Owner:RE, Group:RE, World:RE File organization: Sequential File attributes: Allocation=0 Record format: Stream-CR, no maximum defined Record attributes: Carriage return What does it mean if you have stream-CR and attribute Carriage Return? I mean, yes, each record is separated by a CR, and then what? Add an additional CR at the end of each line? "Record format" refers to the data in the file. Stream_CR means that the records are delineated with a <carriage-return> character. RMS will then populate its internal buffers and the user's buffer upon a $GET with the current record data up to the <carriage-return> character. RMS internal handlers discard this <carriage-return> and update the NRP (Next Record Pointer) leaving it pointing after the <carriage-return> to a subsequent (assuming there is one) record. "Record attributes" refer to how to present the record to the application that performed the $GET to read the record. With "Record attributes" set to "Carriage return", RMS will synthesize a record with <carriage-return> and <line-feed>. If the "Record format" is VFC (Variable Format Control), this synthesis is over-ruled by the format in the VFC header of each and every record. Ah. This do make sense, actually, and matches RSX. (Except there is no Stream_CR, there is only a Stream format.) Perhaps becasue there was no WEENDOZE when RSX was still being developed by d|i|g|i|t|a|l. True. But Windows use CR+LF to terminate lines. That is what Stream deals with anyway, and that is a format used by plenty of other OSes as well. Stream_CR is something I can't remember seeing anywhere in the wild. Maybe something like Wang used something like that, or DG. I think one or the other might have been using pure CR terminated lines in files... (Well, and RSX did continue to be developed into the 90s...) I obviously did not think enough here. However, the actual contents of the file, as seen if I copy it to RSX, totally belies this, as there aren't a single CR in that whole file. But it might be that things are mangled in the process of the transfer. Very likely. I'd think that these files should be maintained on nodes in a format that is much more easily consumed by RMS and DECnet vis a vis a VAR format file. I tried transfer the file in block mode, which should not mess with anything, and it still had only linefeeds. Bob later responded that he used Emacs natively on VMS. So I'd say that VMS creates broken files. They should be Stream_LF, and not Stream_CR, based on their contents. RMS under VMS is forgiving enough to actually let you get away for the most part with this brokenness. But I totally stand by my claim that this is broken. :-) Unfortunately, I already tried it in RSX, and failed, since the whole file appears as just one big line, and Teco on RSX refuse to touch it. Maybe I should teach Teco a new trick - how to read weird stream format files... Yeah, if you lost the actual format coming from VMS (likely, since RSX doesn't have provision for STREAM_CR), then TECO isn't going to fix it up because it will not know where the record boundaries exist. In a way, no. Since TECO honestly couldn't care less about formats anyway, it should be fine. At the worst, I should just have a buffer with all the text separated by simple LFs. Unfortunately, TECO under RSX don't appreciate Stream files at all, since TECO don't even use RMS. TECO uses FCS, and FCS don't have a stream format at all. But it would be easy to fix TECO. I'm going to do that as soon as I have a few minutes over. Johnny