Support ignore and keep empty system environments

[hanrw]

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'

[ryanf5]

Wondering how to do something like envsubst '\$VAR1 \$VAR2' < /filea > /fileb https://github.com/docker-library/docs/issues/496#issuecomment-186149231, I'm happy to file a PR if help needed

[hanrw]

Wondering how to do something like envsubst '\$VAR1 \$VAR2' < /filea > /fileb docker-library/docs#496 (comment), I'm happy to file a PR if help needed

seems that go version not support that but linux version supported.

[2ZZ]

Came here to raise the same request, this tool is really good apart from having to escape env vars. That's tripped me up a few times recently.

[ravensorb]

Any chance of adding an option to leave any vars that are NOT found?

[renato-farias]

I hope this PR address this issue.

[hobti01]

While GNU envsubst does have the ability to specify the variables to substitute, we always use envsubst "$(printf '$%s ' $(compgen -v -X '[a-z]*'))" in order to replace all the variables that are available in the environment. However, this construction is very awkward and relies on other tools - it would be great to have a built-in options to nre: NoReplaceEmpty and nru: NoReplaceUnset or something like that.

ps. I got here from https://mikefarah.gitbook.io/yq/operators/env-variable-operators and this is a great extension to yq.

[dnitsch]

actually I started doing something similar, without reading these issues first 🤦

but yes being strict about only replacing vars found in the provided env would be very useful for a number of scenarios.

the answer might be somewhere in between the 2 PRs, my and this one.

would be good to get somewhere with this.

@hobti01 my PR currently goes for something similar to your approach, however @renato-farias approach may be useful too.

The biggest problem I would see is the lexer throwing away the { } so if a var is present in the "to_replace_input" ${LEAVE_ME_AS_IS} and it's not found in the supplied ENV it would potentially end up as $LEAVE_ME_AS_IS which depending on your use case may not be desirable.

[hobti01]

The biggest problem I would see is the lexer throwing away the { } so if a var is present in the "to_replace_input" ${LEAVE_ME_AS_IS} and it's not found in the supplied ENV it would potentially end up as $LEAVE_ME_AS_IS which depending on your use case may not be desirable.

IMO if the variable is not replaced it should remain unmodified, leaving any unclosing braces.

[dnitsch]

@hobti01 agreed, I think I was just trying to point we need to maintain that behaviour.

@a8m - should we try to get a PR going to introduce this?

All the PRs dealing with this have been closed, as per above I think this is a great feature both for the CLI and the API

[ThaDaVos]

Any update on this?