>  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906250#22 That's an incredibly disingenuous argument. Debian isn't POSIX- compliant by any stretch of the imagination, and they currently don't provide POSIX-compliant cd/umask/wait binaries because they have correctly identified that those binaries are useless and never called by other programs, *ever*. Using that argument to deny getting binaries that actually implement the same functionality in a useful way is nothing short of dishonest. No shell will ever defer to external commands to implement cd, umask or wait, because those commands cannot work as external programs. It simply makes no sense to have them in external programs - unless they exec into the rest of their command line, which is exactly what the execline versions of these programs do. If writing POSIX-compatible versions of cd and umask (as in, accept the POSIX-defined options), that *additionally* exec into the rest of their command line when one is provided (and exit 0 otherwise), which is not forbidden by POSIX, would appease Debian developers, I can do it: it's not that much bloat. Unfortunately, the same approach isn't possible for wait, because there has to be a way to separate the list of pids from the rest of the command line. execline uses a block for this; POSIX just assumes the wait command isn't followed by a command line and only takes a list of pids. This *forces* the wait command to be a shell intrinsic. Such a "wait" *cannot* be implemented as an external program: it would simply not be able to wait for the given lists of pids, except in a very specific case, "exec wait", where it's run as the last command in a shell script. So, the POSIX requirement to have "wait" available as an external command is entirely nonsensical. Maybe the Debian developers would be okay with a different name: what if the command were named "waitpid" instead? I don't like the idea of changing names (that's a major version bump, and then script porting busywork for all users) but I could make an exception to avoid treading on POSIX, even if that part of POSIX is utterly idiotic.
This bug is closed, and there is now an execline package in Debian Sid, so it seems that some resolution has been settled on. However, I'd still like to understand what's the interpretation of the 'exec-ability' requirement raised in message #22, and its connection with the placement of execline binaries. The wording used in the contained links to POSIX confuses me. If someone feels like explaining, to be concrete, what should a compliant 'execution environment' do when presented a C program that contains an execlp("cd", "cd" "blahblah", (char *)0) or execlp("umask", "umask", "022", (char *)0) call?
The execution environment will exec into cd, which will chdir() to blahblah, then exit. Or it will exec into umask, which will umask(022), then exit. Most useful programs ever. Red Hat distributions provided a /usr/bin/cd program for some time, that did exactly that. Maybe it's still around on Fedora/CentOS. It would not be difficult to make execline's cd and umask POSIX-compliant. But that solution doesn't apply to wait. -- Laurent