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