Colin Booth schrob:
> > If you're referring to
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906250#37
> > then, well, you are fighting against POSIX. There's little choice for
> > Debian in the matter. Taking a hardline stance on such "legal" issues is
> > part of their identity as a distro.
> >
> It doesn't help that neither Adam nor Jakub read the documentation for
> the execline equivalents for cd, umask, or wait.

Why would you say that? They effectively only claim that execline's
cd/umask/wait binaries don't conform to the POSIX specification for
cd/umask/wait. And I think that's uncontroversally true.

> That or they don't know what 'execs into' means.

POSIX requires:
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap01.html#tag_17_06
| However, all of the standard utilities, including the regular built-ins
| in the table, [...]  shall be implemented in a manner so that they can be
| accessed via the exec family of functions as defined in the System
| Interfaces volume of POSIX.1-2008 and can be invoked directly by those
| standard utilities that require it (env, find, nice, nohup, time,
| xargs).

i.e, if you call
    execvp("cd", "cd", /* any other args, */ NULL);
, POSIX says you MUST get the behaviour documented at
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/cd.html
. And if /bin/cd is execline's cd, then you don't.

There's also the imho sensible rationale of e.g.
| find . -type d -exec cd {} \; -exec foo {} \;
| (which invokes "foo" on accessible directories)
for that requirement, even if these are admittedly rare cases.

See Message-ID: <a8fbd02e-0265-3d59-89d1-81048665693c@NTLWorld.COM>
here on the list, from Jonathan de Boyne Pollard for more details.


> Within the context of a shell the builtin will always* take precedence.

True, but not the controversial issue.



> [placing binaries]
> Have you ever considered slashpackage ;)
> 
> In all seriousness though this, with the exception of dropping the s6-
> prefix (and the prefix-appender binary I guess), is what slashpackage
> does. /bin stays uncluttered, commands end up in a PATH-able place, and
> if you want to surprise any systemic shell scripts you have you can
> symlink in replacements to the default PATH. 

Yes, I'm aware of that. Unfortunately, I'm not aware of a unix distro
usable for my general needs implementing /package as their packaging
scheme.
Nix/NixOS does something similar, and is on the short list of distros
I'll consider if Debian goes ahead with the systemd madness.

And FWIW, if I were to create my own distro/OS, I'd do away with $PATH
entirely and have people union-mount stuff into /bin .



> > P.S: I stumbled over this execline oddity:
> > | dollarat     -0 -d a                      # separates by \0
> > | forbacktickx -0 -d a var {gen...} loop... # splits on a
> > IMHO, both should be an error, but at least treat them the same.
> >
> As per the docs for forbacktickx:
> -0 : accept null characters from gen's output, using them as delimiters.
> If this option and a -d option are used simultaneously, the rightmost
> one wins.

Yes, and as per the docs for dollarat:
-0 : use the null character as separator. Any -d argument will be
ignored.

They're both working as advertised. But they have *different* rules for
resolving the case where both -0 and -d are given.
I think that's a lack of UI consistency, and would consider it a bug in
my software.
(And, as I said, I think the best response to getting both -0 and -d
would be erroring out, but that's just an aside.)


cheers,
    Jan