Hi, thanks for a feedback. I am curious about your solution - can you share at least API? There are still parts I don’t like and there are not that much fork/execve abstractions written in C as far I can say :) But glad to see we have reached a consensur for argv [0]
I still object to zproc_add_arg - it’s way too long for such common operation :). I kept that intentionally short. Anyway I see no clear winner between single method, zlist/zlistx and vararg methods. The best would be to have them all as you've said. About formatting. It will use zsys_vsprintf under the hood. We use zproto generated class (fty_proto.h#L325 <https://github.com/42ity/fty-proto/blob/master/include/fty_proto.h#L325>), which generate exactly those kind of methods. Compare those two in a code. I found the first one as extremly convenient. zproc_add_arg (self, “/path/to/backup/%ld/%s”, backup_id, some_file); char *arg = zsys_sprintf (“/path/to/backup/%ld/%s”, backup_id, some_file); zproc_add_arg (self, arg); zstr_free (&arg); On Mon, Mar 20, 2017 at 5:30 AM, Procter, Stephen <[email protected]> wrote: > Having recently had cause to write a very similar class (hence > demonstrating the usefulness of this proposal), I thought I’d add my 2 > fils... > > > > Personally I’d pass the executable path to the constructor, and always use > that as both *path* and *argv[0]* - that’s what the spec says should > happen, so make it so. If anyone ever needs to override this default > behaviour for some strange reason, that can come later. > > > > For the args and env, my preference would be for methods which take a list > and a map, respectively: > > > > void zproc_set_args(zproc_t* self, zlistx_t* args); > > void zproc_set_env(zproc_t* self, zhashx_t* env); > > > > These could be provided instead of, or in addition to, the single item > setter methods (which I would probably call zproc_add_arg() and > zproc_add_env(), so they look more like setters and less like getters). > Also I would make the arguments straight const char* strings rather than > format-string-and-arguments, because formatting strings is not what the > class is for; if the caller needs to do that then they can use > zsys_sprintf() to form the arguments. > > > > These are all minor stylistic points however, the main thing is that it > works and is useful! Although your zproc_run() method will, of course, > require a *self* parameter ;-) > > > > Steve > > > > > > *From:* zeromq-dev [mailto:[email protected]] *On > Behalf Of *Michal Vyskocil > *Sent:* 20 March 2017 01:37 > *To:* ZeroMQ development list > *Subject:* Re: [zeromq-dev] [czmq] API design of zproc_run > > > > Hi Luca, > > the "problem" is more ergonomy than anything else. See > http://pubs.opengroup.org/onlinepubs/9699919799/functions/execve.html > > > The argument *arg0* *should* point to a filename string that is > associated with the process being started by one of the *exec* functions > > So following is legal > > ``` > > char **args = {"-c", "ls", NULL}; > > execve ("/bin/bash", args, NULL); > > ``` > > > > it call /bin/bash with argv [0] "-c". My idea is that use path as argv [0] > by default. And when needed it'd be easy to add a code allowing user set > argv [0] to whatever he wants to. > > > > > > On Sun, Mar 19, 2017 at 7:51 PM, Luca Boccassi <[email protected]> > wrote: > > On Sun, 2017-03-19 at 10:07 +0100, Michal Vyskocil wrote: > > Hi, > > > > I have finished a first draft of zproc class for czmq. It should > > provide > > nice and easy to use API to execute and communicate with subcommands. > > I was > > inspired by Python https://docs.python.org/3/library/subprocess.html > > module. zproc use zeromq sockets to pass data in or from the > > subprocess. > > That means that the concept of unix pipes now runs through any libzmq > > transport well :) > > > > Right now it works for libzmq4 and Linux and OSX. > > I tried to make API simple and easy to use and to provide zproject > > API > > model from start. The problem is zproc_run. Right now I simply copy > > execve > > from unix, so the prototype look this way. > > > > int zproc_run (zproc_t *self, const char *filename, char *const > > argv[], char *const envp[]) > > > > > > > > There are three problems > > > > 1. Incompatible with API model > > 2. Does not look really nice to me > > 3. argv [0] is different from filename, so developer must not > > forget to > > pass at least something as argv. > > > > > > > > Given my knowledge of czmq API, I'd say the best way to go is to > > > > // Adds an argument to process command line > > void zproc_arg (zproc_t *self, const char *format, ...); > > > > // Adds an enviroment variable for a process > > void zproc_env (zproc_t *self, const char *key, const char *format, > > ...); > > > > // Execute the subprocess, return -1 if execution fails > > int zproc_run (); > > > > > > So the sample usage would be > > > > > > zproc_t *cat = zproc_new (); > > zproc_arg (self, "%s", "cat"); // Note that filename and > > argv[0] are two distincs things > > zproc_arg (self, "%s", "-A"); > > zproc_arg (self, "%s", "/etc/passwd"); > > > > zproc_env (self, "LC_ALL", "%s", "C"); > > zproc_run (); > > > > > > However I am not convinced if this is the best API ever. And I still > > did > > not solved argv[0] problem. Are there any ideas for better API? > > Looks fine to me! I would recommend having sensible default values when > possible. > > Could you expand a bit more on the argv[0] issue? > > Kind regards, > Luca Boccassi > _______________________________________________ > zeromq-dev mailing list > [email protected] > https://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > > -- > > best regards > Michal Vyskocil > > ------------------------------ > > This transmission is intended solely for the person or organization to > whom it is addressed. It may contain privileged and confidential > information. If you are not the intended recipient, you should not copy, > distribute or take any action in reliance on it. If you have received this > transmission in error, please notify us immediately by e-mail at > [email protected] > > _______________________________________________ > zeromq-dev mailing list > [email protected] > https://lists.zeromq.org/mailman/listinfo/zeromq-dev > -- best regards Michal Vyskocil
_______________________________________________ zeromq-dev mailing list [email protected] https://lists.zeromq.org/mailman/listinfo/zeromq-dev
