ENV-Var escaping might be broken

First of all thanks for the project. Really appreciate it! ❤️

I came across a problem with Env-files. As much as I understand so far docker run and docker compose handle things differently. No idea if I stumbled onto a bug or a feature. Nonetheless this is my problem:

supercronic is run with docker run and the --env-file option. Files used for --env-file are taken as is. They are not escaped. So given this Env-File:

VAR_WITH_BACKSLASH=this-has-a-\-backslash

I get an ENV-Var in the running container with the value this-has-a-\-backslash.

If I run supercronic in said container and give it a cron job like this:

* * * * * env | sort

I get this output:

2026-03-12T17:24:00.042581434Z time="2026-03-12T17:24:00Z" level=info msg="VAR_WITH_BACKSLASH=this-has-a-\\-backslash" channel=stdout iteration=0 job.command="env | sort" job.position=1 job.schedule="* * * * *"

So scripts I try to run via supercronic end up with the wrong Env-Var.

I can work around that by using ESCAPED_VAR_NAME=$(echo -e "$VAR_NAME") in the scripts.

But then the scripts need to be aware of where they are run (via supercronic or e.g. via docker exec)

Any thoughts about that? Is that a bug or a feature?

p.s. I also read that same is true for using quotes in --env-file-Files VAR=some-"-var-with-a-quote. I did not check if superchronic has issues with this as well. Might check tomorrow.

Start by reproducing the reported behavior with docker run --env-file, supercronic, and the sample cron command, then compare the environment value with the value observed through docker exec. No repository file or test is named in the issue; completion would require an agreed expected handling for backslashes and quotes, plus a regression test for that behavior.