🚀 go-pugleaf

> I don't know if this has been submitted to the net before, but I've noticed
> pecular occurance when using the SET HOST/LOG sequence to capture output from
C
> programs using the printf statement.  For instance, the following segment of
> code will print one line and a carriage return to the screen:
>
>                printf("The quick brown ");
>                printf("fox jumped over ");
>                printf("the lazy dog.\n");
>
> This results in:
>                   The quick brown fox jumped over the lazy dog.
>
> However, when running the program after doing a SET HOST/LOG, the output
> in the log file contains:
>                            The quick brown
>                            fox jumped over
>                            the lazy dog.
>
> ...even though the output seen on the screen is correct.  Using DEFINE
> SYS$OUTPUT PROG.LOG to capture the output works as expected, writing one line
> to PROG.LOG.
>
> Anyone got any clues?

I've seen it as well, though not in C; a student came with a Macro program
that was doing similar i/o, and the same problem resulted.  Interesting,
though; to prove that it was a language-independent problem I did the same
thing in Pascal:

          write('The quick brown fox');
          write(' jumped over');
          write(' the lazy dog.');

But to my surprise the SETHOST.LOG file here was okay!  I surmise, then,
that it has to do with how your particular language is handling its i/o
at the lower level.

The problem stems from the fact that that you are writing separate records
to the terminal, although you are saying 'hold the carriage returns and
line feeds'.  Unfortunately, they are still separate records and once they
hit that log file RMS keeps that information.

The fix would probably need to be done in RTTDRIVER or RTPAD.  In fact,
while you're there, DEC, why don't you keep it from putting in the annoying
C/R, L/Fs but handle it like a usual test file?  I use SET HOST/DTE a lot
to access DEC's Software Information Network (since there is no file transfer
support) and it is frustrating to have to strip them out (although admittedly
I've got TPU doing it for me now).

Anyone have any further suggestions?

% Denis W. Haskin                             Manager, Technical Services %
% ----------------------------------------------------------------------- %
% DHASKIN@CLARKU.BITNET   Office of Information Systems     (617)793-7193 %
% Clark University               950 Main Street      Worcester MA  01610 %
%                                                                         %
% "Anyone who _moves_ before Most Holy comes back out will spend the rest %
%  of eternity sipping lava through an iron straw."        - Cerebus      %