Rebar3 shell with +pc unicode?

I have this profile in my rebar.config:

{profiles, [
    {test, [{erl_opts, [debug_info, export_all]}]}
]}.

With this, rebar3 as test shell but not rebar3 shell gives me a shell with everything exported from my modules.

What do I need to add to this to get it to pass +pc unicode? It doesn’t seem to be a {pc, unicode}, {'+pc', unicode}, {erl_vm_args, [{pc, unicode}]}, {erl_vm_args, "+pc unicode"}, {shell, [{vm_args, "vm.args"}]} with +pc unicode as a line in that file, or anything else I can think of.

1 Like

Emulator flags must be specified before rebar3 even starts, that’s why you can’t tweak them in rebar.config. You can use ERL_FLAGS variable to set them:

ERL_FLAGS="+pc unicode" rebar3 shell

or indirectly via vm.args file:

ERL_FLAGS="-args_file <path_to_vm.args>" rebar3 shell

OK. I assumed that rebar3 was spawning a new node for the shell, but it’s an escript and reuses its own node.

Another option then is to rebuild the rebar3 escript to include this argument:

-{escript_emu_args, "%%! +sbtu +A1\n"}.
+{escript_emu_args, "%%! +sbtu +A1 +pc unicode\n"}.

We could set that up. My one concern/fear would be that it would override any sort of expected default in tests or other automation, and possibly undo people’s options if they used ERL_AFLAGS instead of ERL_ZFLAGS when setting their own env-wide options.

That alone makes me a lot more hesitant to play with more command line settings defaults here.

I think overall your concerns make a lot of sense, but isn’t that the exact point of using those variables? (That one can be overridden and the other not, and you’re free to choose which one you prefer)

It is. The inconsistency taking place on someone’s build or test just makes me a bi t extra nervous and I’ve always been overl my cautious.

For example we had that warning on rebar3 shell telling you not to use it in prod for like 4 years if not more I think?

1 Like