[erlang-questions] clarify: run_erl and ssh

[Patrik Nyblom]

Hi Per!

On 12/20/2012 03:56 PM, Per Hedeland wrote:
> Patrik Nyblom <pan@REDACTED> wrote:
>> On 12/19/2012 08:37 AM, Bengt Kleberg wrote:
> [snip]
>>> sekic1152 [8:26am] [/home/eleberg] -> ssh sekic1152 ./afile
> [snip]
>> I guess the PTY does not get initialized correctly when you run via ssh.
> Or rather, in the above command, there is no pty allocated *at all* on
> 'sekic1152'. Try 'ssh -t sekic1152 ./afile' instead. 'man ssh'.
Well, I was unclear or downright misleading.  I did not mean the ssh 
pty, but the pty allocated by run_erl, which can be allocated and setup 
regardless of the stdin/stdout/stderr situation when starting run_erl. 
Or, regardless of everything *except* for the fact that it needs to get 
a valid curses definition, which in turn relies on the terminal setting 
(or TERM environment variable) of the shell that runs run_erl (which is 
expected to match the terminal doing to_erl)...

So ssh does not really need to have allocated a pty, we just need to 
tell run_erl that it should act as if we are going to connect via a 
VT100 (or xterm or something else that has a curses definition). The 
actual pty of run_erl get's initialized correctly regardless, we just 
does not get newshell if we do not have a valid TERM variable so we can 
find a valid curses definition.

That's why

TERM=vt100 run_erl -daemon /tmp/eleberg/ /tmp/eleberg/ "exec erl"

works, but the aforementioned script doesn't (or, really it works, you 
just get the "oldshell").
ssh -t also works, as you then get the TERM variable set properly - it 
is inherited from the remote host in the terminal setup negotiation.

So, saying that the pty did not get properly initialized was wrong, I 
take that back.

Cheers,
/Patrik
>
> --Per Hedeland