I added two flags -no-unset and -no-empty to the envsubst command, with which you can cause the substitution to stop with an error code, should the restriction associated with the flag not be met. This can be handy if you want to avoid creating e.g. configuration files with unset or empty parameters. The flags and their restrictions are:

|Flag | Meaning | | ------------| -------------- | |-no-unset | fail if a variable is not set |-no-empty | fail if a variable is set but empty

These flags can be combined to form tighter restrictions.

Sorry about the fairly large change set...

Hi!

We really need to build this binary for arm64 (we're switching to m1 macs) and I figured it wouldn't be fair to ask you to put any work in so I whipped this up. This PR:

• Tests on Go 1.16/1.17 in github actions
• Automatically builds linux/darwin x86_64/arm64 binaries whenever you cut a release

I'd love it if you'd merge this and cut a release :)

Thank you so much for this project, the -no-unset option was exactly what I was looking for, I've immediately replaced our usage of gettext with it.

Now that I'm a user, would it be possible for envsubst to replace all strings $$foo with $foo?

In my case, I have kubernetes templates for nginx configuration, which I template with some values, but which also contain nginx variables like $remote_user and $bytes_sent strings. My current choices are either to not use -no-unset, or (what I actually do) implement my own escaping with sed.

This code solves #38. It leaves variables untouched which start with a digit. This is the same behavior that the original gnu envsubst has. This change is fully backward compatible. The new functionality get's only enabled when the flag -d is given on the command line or when the new functions are used programatically. Some examples for variables which would not be replaced anymore are:

• $1
• ${1}
• $2ABC
• ${2ABC}

Expressions like $1 get replaced with an empty string, but $1 is by definition no environment variable, because it starts with a digit (See https://stackoverflow.com/a/2821183). This behavior is unexpected different compared to the original gnu envsubst, which does not replace $1.

Turns out this was an upstream breakage and I had to upgrade the action (they fixed it 5 hours ago!), just terrible timing on the merge and I apologize for you wasting a bunch of time on this. Since the upgrade I can run the action in my fork just fine with no failures, so I think we're good again.

#22

Added a flag to override the defualt - fail-fast will enable users to fail fast if required otherwise all errors are displayed in non relaxed modes

If this is intended, apologies... I didn't see it documented.

package main

import (
	"log"
	"github.com/a8m/envsubst"
)

func main() {
	process("Hello $name, how are you?")
	process("Hello ${name}, how are you?")
}

func process(tpl string) {
	out, err := envsubst.StringRestricted(tpl, true, true)
	if err != nil {
		panic(err)
	}
	log.Println("Shouldn't be here - " + out)
}

There needs to be a way to insert dollar symbols in a template Instead of creating a variable (E.G. DOLLAR=\$).

For instance if envsubst was used in a bash script, replacing all the dollars $ with a variable will be messy.

I would like to add support for returning a full list of errors and optionally stop execution on first error. This will be very handy in more complex CI/CD scenarios where config files have a large number of variables to be replaced.

Hi,

nice little helper tool;) Although i recently stumbled over a problem i couldn't find a solution to.. How can i escape sth. like this:

A=${static}

I know about $${static} -> $static. But what if i need the {} ?

regards, Roman

Especially for nginx configs, lots of directives use $lowercase_variable, so having to escape a lot of content.

It would be nice to have an caps-only flag to only detect env vars that are uppercase.

I have a weird issue where envsubst is not working as expected.

When I add only a single a default variable to the right side of the experssion it will work similarly as a default POSIX shell. But when I add additional text to the default it start to do some strange behaviour.

I'll provide some examples, I believe that will be the best description.

sh use case:

docker run --rm -it debian:buster-slim sh
# export VAR1="shouldevaluate"
# export EMPTY_VAR=""
# export MAIN_VAR="${EMPTY_VAR:-$VAR1}"
# echo $MAIN_VAR
shouldevaluate
#
#
# export MAIN_VAR="${EMPTY_VAR:-asdqwe$VAR1}"
# echo $MAIN_VAR
asdqweshouldevaluate
#
#
# export MAIN_VAR="${EMPTY_VAR:-asdqwe $VAR1 qweasd}"
# echo $MAIN_VAR
asdqwe shouldevaluate qweasd
#
#
# export MAIN_VAR="${EMPTY_VAR:-asdqwe${VAR1}qweasd}"
# echo $MAIN_VAR
asdqweshouldevaluateqweasd

And this happens when I try to use the same method in envsubst.

# cat test.template
name = ${EMPTY_VAR:-$VAR1}

name = ${EMPTY_VAR:-asdqwe$VAR1}

name = ${EMPTY_VAR:-asdqwe $VAR1 qweasd}

name = ${EMPTY_VAR:-asdqwe${VAR1}qweasd}
#
#
# envsubst < test.template
name = shouldevaluate

name = asdqwe$VAR1

name = asdqwe $VAR1 qweasd

name = asdqwe${VAR1qweasd}

e.g I have prometheus config below which want only replace CONSUL_URL from system environment. but it will replace $1 left blank there which make metrics_path not correct.

  - job_name: 'consul'
    metrics_path: '/actuator/prometheus'
    consul_sd_configs:
      - server: '${CONSUL_URL:-127.0.0.1:8500}'
        services: [] #match all service
    relabel_configs:
      - source_labels: [__meta_consul_service]
        target_label: job
      - source_labels: [__meta_consul_service_metadata_management_context_path]
        regex: "(.+)"
        target_label: __metrics_path__
        replacement: '$1/prometheus'

I'd suggest the following enhancement of envsubst to be more useful in combination with Docker/Docker Compose or Systemd Unit files:

• Add option to read environment from env files
• Allow multiple env files to be given and process them in order (to override values from former files to support development purposes)
• Add option to ignore the existing shell environment variables and build a fresh environment using the given env file(s) This would greatly simplify some development and deployment processes.