Proposal: Shell history should be enabled by default

I was working on some instructional material today, and I realized that erl/iex still do not support persistent shell history out of the box.

I realize that I can enable this by adding export ERL_AFLAGS="-kernel shell_history enabled" to my ~/.bashrc and opening a new shell… but shouldn’t this feature be enabled by default?

I am wondering if it would be possible to enable this feature by default. If nothing else, it would be one less hurdle for newcomers to jump over when onboarding to the BEAM ecosystem.

Corollary question: Is there a good reason to not enable this feature by default?


What do you think? Should shell history be enabled by default?

  • Yes
  • No
0 voters
1 Like

I’m especially curious to hear from those who have voted no thus far as to the why.

Security is the main reason I can think of. When history is enabled by default, the door is open for persistence of confidential terms without opting into this behavior. Of course, you can counter that and say if someone was able to get access to your shell history, it’s game over anyway, so it’s not a solid reason IMHO :smiley:

You of course would not want this enabled in a release, in the case one is starting a shell on a remote node, but that could be dealt with.

1 Like

In my opinion storing history on local device should always be considered as a default choice. I can only see a privacy concerns, but local storage of a person working in IT is usually safe enough to not worry about that and let’s be honest … who really is copy-pasting secrets into the shell.

2 Likes

I wonder if disabling shell history can be done in no_dot_erlang so that it’s harder to forget to disable it. But that is only tangential to the original question.

There is also a problem of mixing your Erlang and Elixir shell histories in one place, which, I believe, is not handled very nicely today. Making it a default in kernel will do exactly that, so will adding the kernel config setting in one’s .bashrc.

1 Like

I have brought up in the past how it would be nice if iex configured itself to write to a different file.

I think when we have to tell people consistently : do X, do Y, do z as part of getting setup, then that’s a signal that defaults are in order.

It’s a great call out, thanks.

2 Likes

That’s a good point. How is that normally checked? I know there are some environment variables that are set in a release, e.g. RELEASE_ROOT, but is there a better way?

I saw a tip in this post, which is to use this command line argument:

-kernel shell_history_path `pwd | sed 's/.*\///g'`.erl.history

Maybe this behaviour is something that could be standardized as well?

No, there’s various places within a release tools we could just -kernel shell_history disabled (or other form depending on where it’s put), no detection needed.

1 Like

Plus OTP, Mix, Rebar could all default to adding that in their release tools, effecting disabling history in sensitive environments.

4 Likes