[zeromq-dev] [czmq] API design of zproc_run

[Michal Vyskocil]

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 <Stephen.Procter at salik.ae>
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:zeromq-dev-bounces at lists.zeromq.org] *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 <luca.boccassi at gmail.com>
> 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
> zeromq-dev at lists.zeromq.org
> 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
> info at salik.ae
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>



-- 
best regards
     Michal Vyskocil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20170320/6a66d960/attachment.htm>