[erlang-bugs] ssh daemon and encoding.

[Erik Søe Sørensen]

This is probably not related to SSH.
As was found out earlier on this list, the encoding behaviour 
(confusingly) depends on how Erlang was started:

    $ erl -eval 'ok = io:setopts([{encoding, unicode}]),
    io:format("~p~n", [io:getopts()]), init:stop().'
    Erlang R14B03 (erts-5.8.4) [source] [64-bit] [smp:8:8] [rq:8]
    [async-threads:0] [hipe] [kernel-poll:false]

    Eshell V5.8.4  (abort with ^G)
    1> [{expand_fun,#Fun<group.0.120017273>},
      {echo,true},
      {binary,false},
      {encoding,latin1}]
    $ erl -eval 'ok = io:setopts([{encoding, unicode}]),
    io:format("~p~n", [io:getopts()]), init:stop().' -noinput
    [{binary,false},{encoding,unicode}]
    $ erl -eval 'ok = io:setopts([{encoding, unicode}]),
    io:format("~p~n", [io:getopts()]), init:stop().' -noshell
    [{binary,false},{encoding,unicode}]

This has do do with the fact that in one case, the 'group' module 
handles I/O, while in the other case it's the 'user' module.
(I don't know enough to say anything intelligent about why this is, why 
two modules with overlapping functionality but different encoding 
behaviour exist, or what their purposes are besides handling I/O.)

On 31-01-2012 14:00, Fyodor Ustinov wrote:
> Hi!
>
> Unable to set encoding to unicode in ssh daemon session.
>
> ok = io:setopts([{expand_fun, fun expand_prompt/1}, {encoding, unicode}]),
> io:format("~p~n", [io:getopts()])
>
> say:
>
> [{expand_fun,#Fun<group.0.33302583>},
>    {echo,true},
>    {binary,false},
>    {encoding,latin1}]
>
> WBR,
>       Fyodor.
>
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs@REDACTED
> http://erlang.org/mailman/listinfo/erlang-bugs


-- 
Mobile: + 45 26 36 17 55 | Skype: eriksoesorensen | Twitter: @eriksoe
Trifork A/S  |  Margrethepladsen 4  |  DK-8000 Aarhus C | 
www.trifork.com <http://www.trifork.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20120131/e70e9e09/attachment.htm>