What does the parser show when we do this? I have a gut feeling we're addressing this in the wrong spot.

@erikh The parser does show the difference:
(cmd "[ '/bin/sh', '-c', 'echo hi' ]") <-- bad/single quote variant
(cmd "/bin/sh" "-c" "echo hi") <-- good/double quote variant

The questions isn't where the problematic code lives - we know its in the parser - the question is where is the best place to have a test verify that this is what we want to happen given the current state of ambiguity. I can certainly change it so that we have a parser unit testcase that looks for the first variant from above, I just liked the integration-cli test because it verifies that nothing else after the parser modified things and reinterpreted the "string" as a JSON array, thus making the CMD actually work instead of fail.
But I can go either way, just let me know.

None of this is ever handled in the evaluator. I’d prefer to not rely on something as brittle as an error message from busybox if we can avoid it.

Let’s make this a parser test. These were made for these kinds of situations and I’d like to ensure we stay consistent.

On Oct 9, 2014, at 10:21 AM, Doug Davis [email protected] wrote:

@erikh The parser does show the difference:
(cmd "[ '/bin/sh', '-c', 'echo hi' ]") <-- bad/single quote variant
(cmd "/bin/sh" "-c" "echo hi") <-- good/double quote variant

The questions isn't where the problematic code lives - we know its in the parser - the question is where is the best place to have a test verify that this is what we want to happen given the current state of ambiguity. I can certainly change it so that we have a parser unit testcase that looks for the first variant from above, I just liked the integration-cli test because it verifies that nothing else after the parser modified things and reinterpreted the "string" as a JSON array, thus making the CMD actually work instead of fail.
But I can go either way, just let me know.

—
Reply to this email directly or view it on GitHub.

In that case we have: jeztah-invalid-json-single-quotes in there which already covers this case so I would think we could then reject this PR and close the related issue, unless there's a new test you'd like me to add.

Hm. I don’t want to discard a test, but I just don’t see the value add here I guess.

Let’s leave it open for now. @tiborvass what do you say?

On Oct 9, 2014, at 10:42 AM, Doug Davis [email protected] wrote:

In that case we have: jeztah-invalid-json-single-quotes in there which already covers this case so I would think we could then reject this PR and close the related issue, unless there's a new test you'd like me to add.

—
Reply to this email directly or view it on GitHub.

LOL well, if you're just concerned about the strcmp on the error message, I can trash that part of it. The only reason I added it was to make sure that we actually failed for the right reason instead of something else - but there isn't much else to die on so we could just make sure we generate some (any) error and leave it at that.

edit: forgot the "if" in the first line

That works. I’d just rather the test not blow up because we have the busybox image updated (with a new error message).

On Oct 9, 2014, at 10:55 AM, Doug Davis [email protected] wrote:

LOL well, you're just concerned about the strcmp on the error message, I can trash that part of it. The only reason I added it was to make sure that we actually failed for the right reason instead of something else - but there isn't much else to die on so we could just make sure we generate some (any) error and leave it at that.

—
Reply to this email directly or view it on GitHub.

ok, in that case I've updated it.

Thanks @duglin, LGTM.

@crosbymichael not necessary for 1.3, but should be merged after release.

LGTM

awesome @duglin, thank you :)

Can you please rebase this PR?

@crosbymichael done!

LGTM