[erlang-questions] erlang-questions Digest, Vol 24, Issue 20

[John Haugeland]

> Message: 4
> Date: Mon, 4 May 2009 20:49:14 -0400
> From: Andrew Thompson <andrew@REDACTED>
> Subject: Re: [erlang-questions] erlang-questions Digest, Vol 24, Issue
>        15
> To: erlang-questions <erlang-questions@REDACTED>
> Message-ID: <20090505004913.GB6743@REDACTED>
> Content-Type: text/plain; charset=us-ascii
>
> On Mon, May 04, 2009 at 06:51:16PM +0200, Per Melin wrote:
> > You can't. The shell gets in the way and turns your control characters
> > into a printable representation. It's been discussed before on this
> > list.
> >
> > This works though:
> >
> > $ erl -noshell -eval 'io:put_chars([27|"[2J"]).' -s init stop
> >
> > But that helps no one.
>
> +1 on this being really, really annoying behaviour. Would anyone from
> Ericsson care to chime in on what would take to make this at least a
> configurable option (leaving the annoying way as the default for
> compatability)? I'll rework the old patch that's floating around the
> internet if there's any hope of it being merged.
>
> Andrew


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.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20090504/e9b22680/attachment.htm>