Failing to parse env vars with "=" character on its value

Questions / Help
1

Just set up Elixir using asdf in a fresh ubuntu 24.04 installation and I have the weirdest behavior when reading env vars (OTP 27 - Elixir 17)

If I do:

TEST="test" iex
System.get_env("TEST")
"test"

All works as expected, however, if the environment variable has a “=” character

TEST="test=" iex
System.get_env("TEST")
nil

It just won’t find the variable. if I use my previous computer or any other run time in this computer (Python, node etc) everything works just fine. Any help or has anyone seen anything similar? How could I even start to debug something like this? It happens also in the underlying level of the erlang call for reading env vars.

2

I was not able to reproduce that problem:

$ TEST="test=" iex                                                        (main)
Erlang/OTP 27 [erts-15.2] [source] [64-bit] [smp:12:12] [ds:12:12:10] [async-threads:1] [jit]

Interactive Elixir (1.17.3) - press Ctrl+C to exit (type h() ENTER for help)
iex(1)> System.get_env("TEST")
"test="

Is it a shell-related issue? What happens when you run:

TEST="test=" echo $TEST
3

echoing $TEST works just fine. Same if I try to read the variable in other environments (Python and Node executed fine) so I think something is weird in my shell + erlang connection, however, I have the same issue on elixir/erlang using both bash or zsh

4

Works fine on my machine also with Bash.

Perhaps your shell is evaluating the value somehow. Does the same thing still happen if you use single quotes? e.g. TEST='test=' iex

1 Like
5

Same issue with single quotes. If I call env it looks like

TEST=test=
SMT=ok
SMT2=ok

and then

iex
Erlang/OTP 27 [erts-15.2] [source] [64-bit] [smp:22:22] [ds:22:22:10] [async-threads:1] [jit:ns]

Interactive Elixir (1.17.3) - press Ctrl+C to exit (type h() ENTER for help)
iex(1)> System.get_env("SMT")
"ok"
iex(2)> System.get_env("SMT2")
"ok"
iex(3)> System.get_env("TEST")
nil
6

which version of asdf you’re using? i’ve just had this issue and it was a problem with asdf 0.16(the standalone go binary). going back to asdf 0.15(installing with the shell command) had it fixed.

1 Like
7

just for tracking, it was already reported and it should be fixed on asdf 0.16.1

3 Likes
8

…or you guys can use mise because it’s faster and has more features and does not rely on shims and only manipulates PATH which is demonstrably reducing startup time of the tools it manages.

1 Like
9

i tried it a few months ago… i don’t know if i was just too used to asdf, but i felt the docs wasn’t good…
maybe it’s worth to try it again :smile:

10

Not sure what is there to try really. Install, add it to PATH, run commands like install / uninstall / use. Absolutely trivial.

11

@otaviojacobi New version just released: Release v0.16.1 · asdf-vm/asdf · GitHub

EDIT: There’s a migration guide since asdf was rewritten in Go.

1 Like
12

And of course it gets traced back to my custom env var parsing code

:person_facepalming:

That’s why I will give up programming one day. Nobody does things right.

13

just to make you happy… just migrated to mise :stuck_out_tongue:

14

the issue only affected people that “actually” migrated… the same thing didn’t happen on asdf 0.15(that isn’t the standalone go binary).

15

Don’t forget to deactivate asdf so they don’t fight. No need to uninstall it for now. I had asdf installed for a month or so (but still deactivated) until I was satisfied with mise.

16

Thanks all, bumping asdf from 0.16.0 to 0.16.1 indeed solves the issue!

1 Like