On Sun, Dec 22, 2019 at 02:05:14AM +0100, Jan Braun wrote:
> > 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.
>
Fair enough. Pedantic as it was I had mostly taken issue with the
statement that:
Regular "cd" changes the directory for the calling process (thus it
even can't possibly be a separate process), this "cd" takes two
arguments and runs a _child_ with the changed directory.
Which is a false statement unless you consider a program execve'd into
another to be "running a child".
>
> 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.
>
Not sure if this is a legitimate counter but:
find . -type d -exec cd "{}" pwd \;
does what is expected with execline's binary. In fact, I'm not sure if
your hypothetical is valid since I believe each exec is given its own
execution context and cd is not allowed to modify the callers
environment. Of course, I don't think there are any true stand-alone cd
utilities that we can test this with. If you know of one please tell me.
Similarly:
$ nohup /command/cd / pwd ; cat nohup.out
nohup: ignoring input and appending output to 'nohup.out'
/
On third thought, you're specifically talking about the case where you
fail to give a follow-on program to cd. As of v2.5.3.0, the configure
script in execline has grown the --enable-pedantic-posix option which,
when given, will generate a cd that knows how to handle the NULL case.
>
> > [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 .
>
And yet NixOS is also primarily a systemd based distro, unless we have
different definitions of "systemd madness."
>
>
> > > 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.)
>
Fair enough. For some reason I was thinking you were talking about a
documentation error, not a functional inconsistency. I was assuming that
this leaked in when forbacktickx became a wrapper but that isn't the
case, the inconsistency exists as far back as the 2.0.0.0 rewrite.
--
Colin Booth
