[Openmcl-devel] How do I get rid of the extraneous newline on stdout when using CCL in batch mode?

[Gary Byers]

The bad news is that PROCESS-EXIT-APPLICATION indeed calls FRESH-LINE; the
good news is that we can fool FRESH-LINE into thinking that it's already
at the beginning of a line and not output a #\newline.  (Yes, it's ugly,
and the only reason I can think of for that call to FRESH-LINE is that
someone said "but it's not Doing What I Mean"! and no one said "no,
it's doing what you said ...")

Most kinds of streams in CCL have a structure of type CCL::IOBLOCK associated
with them, and most of the stream's state is maintained in fiedls in that structure.
The CCL::IOBLOCK-CHARPOS slot in an IOBLOCK structure is meaningful for character
output streams; it's conceptually set to 0 every time a #\newline is written
to the stream and incremented every time any other character is written to the
stream (so it reflects the stream's notion of the current output column.)
Calling

(ccl::stream-ioblock stream nil)

on a stream will return either a CCL::IOBLOCK struture or NIL, and
(SETF (CCL::IOBLOCK-CHARPOS IOBLOCK) 0)

will basically cause an immediately subsequent FRESH-LINE on the
stream to be a no-op.

PROCESS-EXIT-APPLICATION calls FRESH-LINE to be called on the
streams which are the values of CCL::*STDOUT* and CCL::*STDERR*;
these streams may or may not be EQ.


On Wed, 23 Apr 2014, Kalman Reti wrote:

> lx86cl64 -K iso-8859-1 -Q -b -e '(princ #\1)' < /dev/null > a
>
> produces a file with two characters: the "1" I wanted to write
> followed by a newline that
> I do not want.
>
> I'm trying to write a filter in an environment where I'm constrained
> to use stdin/stdout
> but need to control exactly which bytes are being written...
>
> (I tried to explicitly close *standard-output* after the princ, and
> discovered that the
> newline is created by the process-exit-application method in
> l1-processes; however,
> while closing stdout causes the redirected file to have the correct
> contents in the
> example above, it spews a backtrace to stdout when using in my real environment.
> I thought if there was a catch higher than the toplevel-loop, I could
> throw to that
> instead, but I didn't find such a thing.)
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://lists.clozure.com/mailman/listinfo/openmcl-devel
>
>