$HOME/.erlang is not executed by rebar3 shell

[galdor]

The Erlang documentation states that:

When Erlang/OTP is started, the system searches for a file named .erlang in the user's home directory. If an .erlang file is found, it is assumed to contain valid Erlang expressions. These expressions are evaluated as if they were input to the shell.

When a ~/.erlang file exists, it is indeed executed when running erl. However this is not the case when Erlang is started with rebar3 shell.

This is a problem because ~/.erlang is the only way to alter the Erlang environment without affecting the Rebar3 configuration of the project or the application itself (and thus to force your personal preferences to everyone working on the project). For example, it can be used to configure the Erlang logger with different settings (the default configuration is really impractical for development).

Is there a reason for this ? If this is done on purpose, would there be a way to add a setting to control this behaviour ?

[ferd]

It was never supported, and if it accidentally worked before that was because escripts had it while booting which is out of our control. I think this was covered in a prior issue, but github's search is terribly bad for such a file and I Can't find it.

It's possible this works with rebar3 local install and not the escript just because of how the lookup takes place, but we care for none of these files and just boot the shell from its hidden API calls and a lot of hacks.

[tsloughter]

Eh, I think we should consider caring.

I use ~/.erlang for setting shell history to be per-directory and rely on that being loaded with rebar3. I simply don't use the escript so this works but I don't know that we should have different behaviour because one is run as a shell script and one an escript.

[galdor]

Note that even if it is not currently supported when rebar3 is started as an escript, the shell module could still call c:erlangrc(). I guess the trick would be to call it at the right moment to ensure that the behaviour is the same in all situations (rebar3 started as escript, and rebar3 installed with local install).

[ferd]

if it's installed as local install and currently works then I don't know if calling it twice would actually be safe?

[tsloughter]

If it were added then we'd want to change the shell script to not evaluate it, I think by using the "no dot erlang" boot script or whatever?

[eproxus]

Another vote for this. I have a bunch of debugging helpers in .erlang that would be useful in Rebar shells too.

[eproxus]

For anyone who finds this an wants a workaround:

Add this to your ~/.config/rebar3/rebar.config:

{shell, [{script_file, "/full/path/to/rebar.escript"}]}.

And create rebar.escript somewhere nice (I put mine in ~/.erlang.d/... because that's where I store my normal Erlang user defaults code):

#!/usr/bin/env escript
main(_) ->
    % You can put whatever code you want here
    code:load_abs(filename:join(os:getenv("HOME"), ".erlang.d/user_default")).

If you want to share code between .erlang and your Rebar shell, you can use the structure I use:

~/.erlang
~/.erlang.d
├── rebar.escript
├── user_default.beam
└── user_default.erl

And in .erlang you can have the same line as in the Rebar shell escript:

code:load_abs(filename:join(os:getenv("HOME"), ".erlang.d/user_default")).

[paulo-ferraz-oliveira]

You should make a Gist out of this, @eproxus.

[eproxus]

@paulo-ferraz-oliveira Done https://gist.github.com/eproxus/ff45250c5523974cdf573186563f4080