In log filter hook, bash substitution returning blank string

[caseodilla]

Using the following variables in an env_file in docker: VALHEIM_LOG_FILTER_CONTAINS_Connected=Got connection SteamID ON_VALHEIM_LOG_FILTER_CONTAINS_Connected='{read l; l=${l//*SteamID /}; msg="$l logged on"; curl...}' the $l ends up being a blank string, so $msg only returns " logged on".

After troubleshooting, I found that read l does bring in the correctly populated string at first, but it's after the bash substitution expression l=${l//*SteamID /}; that the string becomes empty.

When I run bash on the docker image, I'm able to perform the same substitution successfully, resulting in $l containing only the numerical SteamID, but it appears to fail when being executed by the log hook.

[caseodilla]

Little more troubleshooting.

Whereas the env_file reads: ON_VALHEIM_LOG_FILTER_CONTAINS_Connected=read l; id=${l//*SteamID /};...

Running bash on the docker image and using printenv shows the variable completely loses the substitution string: ON_VALHEIM_LOG_FILTER_CONTAINS_Connected=read l; id=;...

So something does not like the ${l//*SteamID /} reference even when passing the variable to the docker image in the first place. I've tried using escape characters, double quotes, and single quotes on that substitution expression, but nothing works.

[caseodilla]

I've figured it out. When using the env_file to pass in the variables, the substitution expression appears to get evaluated by the host machine before getting passed into the docker container.

My solution was to not use an env_file, rather define everything directly in the docker-compose.yaml. This requires some tweaking.

env_file version: ON_VALHEIM_LOG_FILTER_CONTAINS_Connected=read l; id=${l//*SteamID /};... docker-compose.yaml version: - 'ON_VALHEIM_LOG_FILTER_CONTAINS_Connected=read l; id=$${l//*SteamID /};...'

Note the entire string must be surrounded by single quotes, and $ must be switched to $$.

@lloesche - I imagine this is the root cause to the handful of similar issues that are reported, such as #455 and #296. Since you were able to use the substitution expression in an env_file, might this be distro-dependent?

[NubemInvidia]

Just wanted to add, I have been using Ubuntu 22.04 if it does indeed turn out to be distro related

[caseodilla]

Same distro here.