[erlang-bugs] ssh daemon and encoding.

[Fyodor Ustinov]

On 01.02.2012 18:50, pan@REDACTED wrote:
> Hi Erik!
Can I expect that it will be seen as a bug and corrected in the next 
version?
>
> 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/>
>>
>
>
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs@REDACTED
> http://erlang.org/mailman/listinfo/erlang-bugs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20120201/d35a1a7a/attachment.htm>