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

Fred Hebert mononcqc@REDACTED
Thu Apr 25 13:51:35 CEST 2013


On 04/25, Ignas Vyšniauskas wrote:
> Hi Scott, Fred,
> 
> On 04/24/2013 03:46 PM, Fred Hebert wrote:
> > - If it's not possible to boot the tty used by 'user_drv', it should
> > fall-back to 'user.erl' as an IO leader.
> 
> So how does Erlang determine whether TTY is available? 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?
> 

There's a code snippet in user_drv.erl (lines 92-109) that does the
detection of whether it's possible to spawn things:

    server(Pname, Shell) ->
        process_flag(trap_exit, true),
        case catch open_port({spawn,Pname}, [eof]) of
            {'EXIT', _} ->
                %% Let's try a dumb user instead
                user:start();
            Port ->
                server1(Port, Port, Shell)
        end.

    server(Iname, Oname, Shell) ->
        process_flag(trap_exit, true),
        case catch open_port({spawn,Iname}, [eof]) of
            {'EXIT', _} -> %% It might be a dumb terminal lets start dumb user
                user:start();
            Iport ->
                Oport = open_port({spawn,Oname}, [eof]),
                server1(Iport, Oport, Shell)
        end.

The interesting clauses are the 'user:start()' fallbacks. Basically,
whenever the user_drv cannot spawn the desired port program (Erlang's
tty driver started as 'tty_sl -c -e'), it will fall back to the old
shell by default.

I'm thinking the two valid approaches are those I discussed with Robert
Virding and Andrew Thompson off the mailing list yesterday -- either
have lager not produce output to 'user' when it detects the old shell
(which is what Andrew and Scott ended up going with iirc), or fixing the
old shell the way I mentioned in another post. This would be the
solution where the function that currently blocks the shell is able to
forward output anyway -- something Robert told me he believes it did in
the past.

If the old behaviour was to forward the output and now it's gone (I
haven't checked, but I'm ready to trust Robert on that), then this would
be a regression bug that needs to be fixed by the OTP team (or any
contributor with the time to do it) within user.erl.

Regards,
Fred.



More information about the erlang-questions mailing list