[ksh93-integration-discuss] Shouldksh93/libshelluse|posix_spawn()| instead of |vfork()| ?

[Glenn Fowler]

On Mon, 30 Oct 2006 10:53:27 -0500 Greg Nakhimovsky - Sun MDE wrote:
> Glenn Fowler wrote:
> ...
> > I fixed those, but posix_spawn() was still found unworthy
> > the reason is that at least on solaris 10, posix_spawn() returns 0 (success)
> > when the executable file is empty
> > truss shows the underlying execve() getting ENOEXEC (which it should),
> > but that errno fails to make its way back as the posix_spawn() return value
> > 
> > note that linux posix_spawn() is not worthy for the same reason

> Most likely, posix_spawn() is supposed to return 0 (success) when 
> the executable file is empty. It IS a little weird and confusing 
> indeed, but that's how POSIX defined this interface.

first let's clarify that "empty" is not the key characteristic here
any content besides a valid a.out magic number still results in "success"
even though the underlying implementation fails with ENOEXEC

the posix_spawn() spec is careful to use the same language (regular executable file)
as it does for execv() -- execv() returns failure with errno set to ENOEXEC
for executable files with bad magic

it specifically states that the executable file shall be executed as if
 "a member of the exec family of functions had been called by the child
  process to execute the new process image"

any reading of posix_spawn() that allows it to return 0 (success) for 
regular executable files on which execv() would fail is flawed

otherwise how could a shell using posix_spawn() know that an execution
actually failed? 

after all, the prototypical method of marching down PATH is to exec() with
each PATH element until success or the PATH is exhausted

-- Glenn Fowler -- AT&T Research, Florham Park NJ --