<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Message: 4<br>
Date: Mon, 4 May 2009 20:49:14 -0400<br>
From: Andrew Thompson <<a href="mailto:andrew@hijacked.us">andrew@hijacked.us</a>><br>
Subject: Re: [erlang-questions] erlang-questions Digest, Vol 24, Issue<br>
        15<br>
To: erlang-questions <<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a>><br>
Message-ID: <<a href="mailto:20090505004913.GB6743@hijacked.us">20090505004913.GB6743@hijacked.us</a>><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
On Mon, May 04, 2009 at 06:51:16PM +0200, Per Melin wrote:<br>
> You can't. The shell gets in the way and turns your control characters<br>
> into a printable representation. It's been discussed before on this<br>
> list.<br>
><br>
> This works though:<br>
><br>
> $ erl -noshell -eval 'io:put_chars([27|"[2J"]).' -s init stop<br>
><br>
> But that helps no one.<br>
<br>
+1 on this being really, really annoying behaviour. Would anyone from<br>
Ericsson care to chime in on what would take to make this at least a<br>
configurable option (leaving the annoying way as the default for<br>
compatability)? I'll rework the old patch that's floating around the<br>
internet if there's any hope of it being merged.<br>
<br>
Andrew</blockquote><div><br>There are good reasons for this behavior.  Remember that this is a realtime protocol translation language, that it needs to be binary safe everywhere, and that it expects to dump horrible crashes to the console.  As such, the ability to print binary safely to the console and expect character output rather than interpreted output is important.<br>
<br>It is my opinion that it's important for you to ask yourself a question: do you want color and console control, or do you want specifically ANSI/VT codes?  If you just want color and console control, why stick to ANSI/VT codes, or indeed even formatting in-datastream?  They're limiting, inelegant, they make ugly code, they're not particularly pervasive these days, and they introduce significant problems for a language that wants binary safe dump to console.<br>
<br>How would you feel about the pen mechanism as described earlier, by contrast?  It would have the advantage of not affecting existing software, retaining the power to dump raw data to console without fear, would not limit you to what ANSI can do, and would end up with far more readable/maintainable code; at the same time it would not inject control codes into non-parsing interfaces, potentially breaking parsed upstream pipes and logging mechanisms.<br>
</div></div><br>