[erlang-questions] "New" vs. "old" console behavior: bug or feature?

[Ignas Vyšniauskas]

Hi Scott,

On 04/25/2013 07:20 PM, Scott Lystig Fritchie wrote:
>> Ignas Vyšniauskas <baliulia@REDACTED> wrote:
>>
>> Currently I've worked around this by forcing a `SHELL=screen`
>> variable in the boot script and it seems to do the trick, but I
>> don't really like this approach. Any suggestions?

[I obviously meant `TERM=screen`.]

> Ignas, the Expect script that I put in my original/long message to
> this list contains a magic workaround.  In the case where run_erl
> (on box A) is started via SSH from a remote box (call it box B).

Well, in fact you don't need the whole "ssh and several boxes" setup to
reproduce the problem, I think this works too:

1. Generate a release of some project
2. Start the release pretending to have no tty capabilities: `TERM=
./rel/node/bin/node start`
3. Attach, input something without termination
4. Trigger some logging via `io:format(user, <..>)` (e.g. by lager)
5. Observe processes hanging, rejoice.

> If box B uses "ssh -t" to force the allocation of a pseudo-tty on
> box A before executing "run_erl", then the problem goes away because
> the VM can use the new shell.

Yes, but the problem with that is that it leaves it up to the user/admin
to ensure that the release is started in an environment which claims to
have decent term capabilities, which is something non-obvious and annoying.

After reading a bit, I realise setting TERM *is* essentially the only
way to advertise term capabilities, so I might settle for something like

     if [[ -z $TERM || $TERM == "dumb" ]]; then export TERM=screen; done

inside of the release start script, which is hackish, but I think it
prevents the problem from happening regardless of how the node is
started and also has the nice side-effect of proper tab completion and
etc everywhere.

--
Ignas