[erlang-questions] "New" vs. "old" console behavior: bug or feature?
Thu Apr 25 22:48:09 CEST 2013
On 04/25/2013 07:20 PM, Scott Lystig Fritchie wrote:
>> Ignas Vyšniauskas <> 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=
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
More information about the erlang-questions