> [1] 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
Received on Sun Sep 09 2018 - 20:17:16 UTC