config.md: args of Hooks should be optional #685
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Ma Shimiao <mashimiao.fnst@cn.fujitsu.com>
wking
reviewed
Feb 9, 2017
| @@ -328,7 +328,7 @@ Hooks allow for the configuration of custom actions related to the [lifecycle](r | |||
| Entries in the array contain the following properties: | |||
| * **`path`** (string, REQUIRED) with similar semantics to [IEEE Std 1003.1-2001 `execv`'s *path*][ieee-1003.1-2001-xsh-exec]. | |||
| This specification extends the IEEE standard in that **`path`** MUST be absolute. | |||
| * **`args`** (array of strings, REQUIRED) with the same semantics as [IEEE Std 1003.1-2001 `execv`'s *argv*][ieee-1003.1-2001-xsh-exec]. | |||
| * **`args`** (array of strings, OPTIONAL) with the same semantics as [IEEE Std 1003.1-2001 `execv`'s *argv*][ieee-1003.1-2001-xsh-exec]. | |||
There was a problem hiding this comment.
If we're thinking about adjusting this, I still prefer Python's approach which makes path optional. I'd also like to unify the approach to process invocation between hooks and process (having different semantics for args depending on the context is just confusing). But if those are not on the table, this change looks ok to me, and gets us back closer to the old Go semantics with their optional Args.
There was a problem hiding this comment.
+1 for keeping consistency for args's semantics between process and hooks, either current version for process or go semantics works for me.
|
LGTM |
1 similar comment
|
LGTM |
|
On Wed, Feb 15, 2017 at 02:12:48PM -0800, Mrunal Patel wrote:
Merged #685.
My reading of the language this landed is that:
{
…
"hooks": {
"prestart": [
{
"path": "/foo/bar"
}
]
}
}
would invoke /foo/bar with an empty/unset argument list. Something
like:
$ head *.c
==> x.c <==
#include <stdio.h>
int main(int argc, char **argv) {
printf("invoked with argc = %d\n", argc);
return 0;
}
==> y.c <==
#include <unistd.h>
int main(int argc, char **argv) {
execv("./x", NULL);
return 1;
}
$ gcc -o x x.c
$ gcc -o y y.c
$ ./y
invoked with argc = 0
Was that the intention?
Or was the intention to restore the old Go semantics where ‘args’
falls back to ‘[path]’ if ‘args’ was unset [1]? If so, we probably
need a follow-up PR that updates the ‘args’ documentation to specify
the fallback.
[1]: https://golang.org/pkg/os/exec/#Cmd
|
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Signed-off-by: Ma Shimiao mashimiao.fnst@cn.fujitsu.com