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

Mon Mar 20 06:31:44 CET 2017

Hi Michal,

Yes agreed, if a particular method signature is convenient for your use-case then it makes perfect sense to do it that way. The zproto code generation is neat, I’ve never used it but will have to find a reason to look into it myself!

I’ll reply further off-list before we stray too far off-topic...

Steve

From: zeromq-dev [mailto:zeromq-dev-bounces at lists.zeromq.org] On Behalf Of Michal Vyskocil
Sent: 20 March 2017 09:12
To: ZeroMQ development list
Subject: Re: [zeromq-dev] [czmq] API design of zproc_run

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<mailto: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<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<mailto: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<mailto: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<mailto:info at salik.ae>

_______________________________________________
zeromq-dev mailing list
zeromq-dev at lists.zeromq.org<mailto: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/0440f2f2/attachment.htm>