Assuming that we can agree that the environment value should be accepted as a scalar (rather than a YAML), what you need to do is:

1. free(node->data.scalar)
2. initialize node->data.scalar to a string that can be freed using free (e.g. h2o_strdup(NULL, s, SIZE_MAX).base)
3. increment the refcount of the node
4. return the node

@kazuho i just realised that only scalars might not be useful enough.
how about numbers? probably the most obvious thing you want to sed is e.g. num-threads.
also being able to use anchors would be neat, so you can "implement" simple switches.

i actually do not see any downside (except for the more complex code) to parsing it correctly.
what do you think?

@yannick

i just realised that only scalars might not be useful enough.
how about numbers? probably the most obvious thing you want to sed is e.g. num-threads.

In YAML there is no distinction between strings and numbers. Both are scalars.

also being able to use anchors would be neat, so you can "implement" simple switches.

I would rather not take that into consideration when making the decision. I do not think having room to "hack" is bad, but having a straightforward design is more important.

i actually do not see any downside (except for the more complex code) to parsing it correctly.

Users would be required to encode the environment variable in YAML, which is not an easy task.

Consider the case where a script accepts some argument and convert that to a environment variable to be used for substitution in the configuration file. The script would be required to convert the argument to YAML, otherwise things could go wrong depending on the argument.

Not only implementing such escaping is difficult, it is very easy for the author of script to forget implementing it. That means that we could see issues in production...

My anticipation is that majority (if not most) of the use-case can be covered by just supporting scalars to be supplied with environment variables. So I think we should not require escaping for the use case, instead of making it difficult for all users.

thank you for the clarifications, i think it makes sense. i'll change the implementation