Re: Compile-time detection of EOL translation mode (CLISP)

["Aaron Brown" <arundelo at hotmail dot com>]

Reini Urban wrote:

> For me [defined(WIN32)] is true during clisp compilation.
> I had to change the patch to fix the WIN32 section, not
> the UNIX one. I'll check which optional header defines
> WIN32.

I did actually test it to make sure I wasn't misremembering
it being false.  I haven't found any official Cygwin
documentation on WIN32, but a few mailing list posts also
say it should be false:

 http://www.cygwin.com/ml/cygwin/2005-03/msg00614.html
 http://www.cygwin.com/ml/cygwin-apps/2000-11/msg00043.html

> There's a setter, but not easy to find.

> [5]> (setq *terminal-encoding* (ext:make-encoding :line-terminator :unix))
> #<ENCODING CHARSET:ISO-8859-1 :UNIX>

This apparently doesn't work when stdout isn't a terminal.
E.g., running the following

 clisp.exe -i .clisprc test.lisp > test.txt

(where .clisprc does the above setq and test.lisp just
prints several lines) results in

 *** - SYSTEM::SET-STREAM-EXTERNAL-FORMAT on
        #<IO TWO-WAY-STREAM #<IO TERMINAL-STREAM>
          #<OUTPUT BUFFERED FILE-STREAM CHARACTER #P"/dev/fd/1">>
       is illegal

If I have .clisprc do

 (setf (stream-external-format *standard-output* )
   (make-encoding :line-terminator :unix))

and stdout is not a terminal, then there's no error, but
test.txt is still in dos format.  (Of course output
redirections like this are exactly why I care about EOLs.)

If you think it's a good idea, we can take this discussion
to the CLISP list.

Thanks,

--
Aaron
Beginning Lua Programming: http://www.amazon.com/gp/product/0470069171/

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/