I believe the reason you see what you see is that when in DisplayFunctions
mode, a CR causes a linefeed, while an LF does not.  So DisplayFunctions
isn't "pure". (it won't show you NUlls, either, one great reason for keeping
an HP2645A around, which has "monitor mode").

Tracy Pierce

> -----Original Message-----
> From: Newton, Tony [mailto:[log in to unmask]]
> Sent: Thursday, April 12, 2001 1:32 PM
> To: [log in to unmask]
> Subject: Re: Searching for the whole CR/LF story
>
>
> 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       *
>

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