[erlang-bugs] ssh daemon and encoding.

[pan@REDACTED]

Hi Erik!

You are absolutely right about that 'user' and 'group' are used in 
different situations and that the names are utterly confusing. 'group' is 
used in *interactive shell sessions* and will determine unicode mode from 
LOCALE/terminal settings, while 'user' is for non interactive stdin/stdout 
(pipes, redirected files, dumb terminals etc), in which case you *have to* 
set unicode mode manually. Your first example will run the io:setopts 
before the group server is fully initialized, why you will get an 
unexpected behaviour. If you were to do the same when the interactive 
shell was actually started, the behaviour would be as expected.

If opting to set unicode mode for an interactive session, set the LOCALE 
correctly. If running a non interactive session, use -oldshell or 
-noshell and do as in your second example.

The problem reported however, was easilly found. It is due to that ssh_cli 
does not handle setting of unicode mode, which is a problem in the ssh 
application (that does not fully handle unicode). The internal protocol 
between io-server and ssh_cli will call 
ssh_cli:handle_msg({Pid,set_unicode_state,true},State), which is ignored 
by the ssh_cli code. Supporting unicode here could be done by simply 
expecting the terminal in the other end to support UTF8 characters if 
unicode mode was enabled, which would be the same behaviour as in the 
'user' io-server. That however requires a fair amount of coding and the 
ssh application is far away from my jurisdiction :)

Cheers,
/Patrik, OTP


On Tue, 31 Jan 2012, Erik Søe Sørensen wrote:

> 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/>
>