Actually we are just printing it through a Reflection/Minisoft terminal
emulator. So, with "Display Functions" turned on then I guess we are seeing
whatever is actually in the file but the emulator then chooses the format on
how to display it?

The root cause of this question stems from a contractor who is FTP'ing files
down to his PC for editing and then FTP'ing them back to the e3000.  He says
that upon upload he is losing the last LF in the file.  He is using build
parms when FTP'ing them back however I'm not exactly sure what he's using as
build parms since he's at lunch.  So, upon investigating it further I ran
into this question(Which was just more for my personal knowledge than for a
root cause of the above problem).

___
Tony Newton


> -----Original Message-----
> From: Gavin Scott [mailto:[log in to unmask]]
> Sent: Thursday, April 12, 2001 1:14 PM
> To: Newton, Tony; [log in to unmask]
> Subject: RE: [HP3000-L] Searching for the whole CR/LF story
>
>
> Tony writes:
> > I have a file that has 2 LF's and 1CR at the end of each line,
> > however when I look at it with "Display Functions" turned on
> > in Reflection there are no additional lines in between each
> > line of data.
>
> > FILENAME  CODE  ------------LOGICAL RECORD-----------  ----SPACE----
> >                   SIZE  TYP        EOF      LIMIT R/B  SECTORS #X MX
> > DMEMBR03         8960B  VA       23216      50000   1    31936 19 32
>
> What are you using to view the file?  If it's a "Posix" program that's
> expecting to see byte stream files, be aware that your file is an MPE
> variable length file and if the program asks for byte stream
> access (any
> standard shell program or anything else linked with the
> "Posix" version of
> the C library) then it's going to be hooked up to the
> bytestream emulator
> which is going to make you think that there's an extra LF
> character in the
> file located between each MPE record.
>
> Doing a binary tobyte on the file might eliminate your
> "extra" LFs if that's
> what you want to do.
>
> Lots of programs try to be clever in their handling of LS vs.
> CRLF vs. CR
> line separators and in handling redundant separators, so you
> can't always be
> sure that what you get is what you see.
>
> G.
>

This message is intended for the sole use of the individual and entity to
whom it is addressed, and may contain information that is privileged,
confidential and exempt from disclosure under applicable law.  If you are
not the intended addressee, nor authorized to receive for the intended
addressee, you are hereby notified that you may not use, copy, disclose or
distribute to anyone the message or any information contained in the
message.  If you have received this message in error, please immediately
advise the sender by reply email and delete the message.  Thank you very
much.

* To join/leave the list, search archives, change list settings, etc *
*     please visit http://raven.utc.edu/archives/hp3000-l.html       *