Implement InputKind Env

[SteveL-MSFT]

Summary of the new feature / enhancement

InputKind = Args is intended for simple cases like bash script resource where a flat JSON schema would result as name/value pairs sent as parameters and parameter values to the script:

{
  "property1": 1,
  "property2": "hello"
}

Would result in:

yourresource -property1 1 -property2 "hello"

Proposed technical implementation details (optional)

No response

[michaeltlombardi]

Do we need a way to distinguish between --flag and -f or should we always assume the former as convention for xplat executables?

[SteveL-MSFT]

Yes, I hadn't thought about this until I read your draft doc. Even worse, on Windows, it's not uncommon to see /f. So I think args InputKind probably needs an optional member called prefix which defaults to --, but can be set to whatever is needed.

[SteveL-MSFT]

Complex/nested objects won't be supported for this and will error rather than trying to pass JSON fragment

[SteveL-MSFT]

Was thinking about this and looked up how to parse args in Bash. It's actually quite complicated and requires not obvious code. Like batch files, it's more optimized for positional parameters. Instead, it's much easier to deal with env vars. So I'm changing this to passing input as named env vars.

[michaeltlombardi]

Should we not support both? Or are we prioritizing env vars now and args later?

[SteveL-MSFT]

We can add args support when a use case comes up