From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2774 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Colin Booth Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: s6 usability Date: Sun, 22 Dec 2019 08:30:24 +0000 Message-ID: <20191222083024.GC12551@cathexis.xen.prgmr.com> References: <20191125214342.y7lx5mixrljr6s27@gromit.local> <20191127203307.ohaameqfgncm52h5@gromit.local> <20191129140901.klifpegc74iv4zul@klumpi.ignorelist.com> <20191221092639.p5iid3y3csmni4iw@klumpi.ignorelist.com> <20191221211914.GB12551@cathexis.xen.prgmr.com> <20191222010514.sklyo7fmo7ftpcxt@klumpi.ignorelist.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="251766"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) To: supervision@list.skarnet.org Original-X-From: supervision-return-2363-gcsg-supervision=m.gmane.org@list.skarnet.org Sun Dec 22 09:30:28 2019 Return-path: Envelope-to: gcsg-supervision@m.gmane.org Original-Received: from alyss.skarnet.org ([95.142.172.232]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1iiwdA-0013LU-12 for gcsg-supervision@m.gmane.org; Sun, 22 Dec 2019 09:30:28 +0100 Original-Received: (qmail 28747 invoked by uid 89); 22 Dec 2019 08:30:53 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Original-Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Original-Received: (qmail 28740 invoked from network); 22 Dec 2019 08:30:52 -0000 Content-Disposition: inline In-Reply-To: <20191222010514.sklyo7fmo7ftpcxt@klumpi.ignorelist.com> Xref: news.gmane.org gmane.comp.sysutils.supervision.general:2774 Archived-At: 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