On Tue, Nov 20, 2012 at 10:37 AM, Cedric Blancher <[email protected]> wrote: > On 1 October 2012 19:11, Glenn Fowler <[email protected]> wrote: >> >> On Mon, 01 Oct 2012 13:49:28 +0200 Michal Hlavinka wrote: >>> > #if _lib_posix_spawn < 2 >>> > if (waitpid(pid, &err, WNOHANG|WNOWAIT) == pid && EXIT_STATUS(err) == >>> > 127) >>> > { >>> > while (waitpid(pid, NiL, 0) == -1 && errno == EINTR); >>> > if (!access(path, X_OK)) >>> > errno = ENOEXEC; >>> > pid = -1; >>> > } >>> > #endif >> >>> It will fail with EINVAL, because of WNOWAIT. This option is not >>> supported in waitpid. It's supported only in waitid(). >> >>> so you'd have to use something like >> >>> pid_t pid; >>> siginfo_t err; >>> if (!waitid(P_PID, pid, &err, WEXITED|WNOHANG|WNOWAIT) && err.si_status >>> == 127) >> >> thanks for pointing out the WNOWAIT misuse >> >> alas even with the correct waitid() usage it does not solve the problem >> with all posix-spawn() implementations that use exit code 127 as a catch all >> for >> posix_spawn() related problems in the child process >> >> in the particular case of how shell implementations *portably* determine >> "binary executable" vs "shell script" (exec fails with ENOEXEC) >> such posix_spawn() implementations are useless >> >> e.g. a shell calling posix_spawn() must be able to differentiate >> EAGAIN retry in case some resources become free >> E2BIG diagnostic or apply xargs algorithm if appropriate >> ENOEXEC either a shell script or a diagnostic >> and you can't get that from exit status 127 > > So GNU/Linux glibc posix_spawn() is still violating the standard here?
No, it still does not pass the posix_spawn() parts of the POSIX VSX-PCTS2003 test suite, for exactly the reasons Glenn listed in his previous email. Irek _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
