On Tue, Oct 28, 2008 at 05:04:25PM -0700, Sumanth Naropanth wrote: > > What's the rationale for this name? Are there similar functions in > > other Unix or Unix-like operating systems? > > The intention is to provide a very system()-like interface that doesn't > execute using the shell. The new function uses execve() (via > posix_spawn()) to do the actual execution and hence 'exec_system()'.
I don't think a quoting scheme other than the traditional Bourne Shell quoting scheme is simple. > >> The special character '\377' is chosen since it lies outside the > >> printable character set. This quoting mechanism will make it harder for > > > > Is that true for *every* character set and encoding scheme that we > > support or might support? It's true for US-ASCII and for UTF-8, for > > example, but not for ISO8859-1, for example. > > I agree that it's not impossible to supply '\377' as an input when some > encoding schemes may allow for it. Using '\377' makes it much harder > (but not completely impossible) to trick the argument parsing than using > single/double quotes. If you really want a single const char * AND you want arguments, then the result won't be simple to use and/or code. > > Moreover, why even have a quote character? Make this function take a > > variable number of arguments, with the last being NULL, and be done. > > Sounds like a good idea, but that pulls it away from a simple (const > char *) interface. I'll give this more thought. Thanks! Many a system(3C) caller formats that string using snprintf() (or whatever). So, format, then parse... that's not simple. Granted, some system(3C) callers just use a constant string. But variable arguments lists are not difficult for such callers to handle. I think a variable arguments list is the way to go. > > Maybe the user ID (real or effective) to use should be an argument, as > > well as whether to drop privs. > > This feature mimics the behavior of system(3C) when it's used inside > setuid program. Again, it's a trade-off between providing an extended > functionality (to allow execution as effective user) versus keeping the > interface simple and less daunting. You'll eventually add yet a new version. > >> The exec_system() implementation will extend the signal handling model > >> of system(3C) and will set SIGCHLD to be blocked for the calling thread, > > > > Why not use forkx() to avoid SIGCHLD issues altogether? > > > > Using posix_spawn()/waitpid() allows me to pass the return value of the > execve() call back to the parent process when exec fails. I don't > suppose forkx()/exec() will allow for that (apart from just causing the > child to exit(127))? forkx() certainly allows you to waitpid(). Maybe we need a forkx() flag to do vfork() so posix_spawn() can use it? Nico --
