From: Jan Braun <janbraun@gmx.de>
To: Colin Booth <colin@heliocat.net>
Cc: supervision@list.skarnet.org,
Laurent Bercot <ska-supervision@skarnet.org>
Subject: Re: s6 usability
Date: Sun, 22 Dec 2019 02:05:14 +0100 [thread overview]
Message-ID: <20191222010514.sklyo7fmo7ftpcxt@klumpi.ignorelist.com> (raw)
In-Reply-To: <20191221211914.GB12551@cathexis.xen.prgmr.com>
[-- Attachment #1: Type: text/plain, Size: 3662 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2019-12-22 1:05 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-25 21:43 runit patches to fix compiler warnings on RHEL 7 J. Lewis Muir
2019-11-27 20:33 ` J. Lewis Muir
2019-11-28 7:59 ` Ben Franksen
[not found] ` <ecdf4d8f-93f6-3f9f-b84c-351fa91c7f02@uni-bremen.de>
2019-11-28 19:04 ` Laurent Bercot
2019-11-28 20:39 ` Steve Litt
2019-11-28 22:17 ` runit or s6 (was: runit patches to fix compiler warnings on RHEL 7) Laurent Bercot
2019-11-29 14:09 ` runit patches to fix compiler warnings on RHEL 7 Jan Braun
2019-11-29 21:46 ` Dewayne Geraghty
2019-11-30 1:22 ` Colin Booth
2019-11-30 0:21 ` Colin Booth
2019-11-30 3:14 ` Steve Litt
2019-11-30 13:32 ` Jeff
2019-11-30 13:46 ` Jeff
2019-11-30 10:15 ` s6 usability (was: runit patches to fix compiler warnings on RHEL 7) Laurent Bercot
2019-11-30 14:32 ` Jeff
2019-11-30 18:58 ` Laurent Bercot
2019-12-02 12:07 ` Jeff
2019-12-02 22:20 ` Laurent Bercot
2019-12-02 2:47 ` Steve Litt
2019-12-02 3:37 ` s6 usability Dewayne Geraghty
2019-12-02 10:24 ` fungal-net
2019-12-02 21:32 ` s6 usability (was: runit patches to fix compiler warnings on RHEL 7) Laurent Bercot
2019-12-02 23:17 ` s6 usability Samuel Holland
2019-12-03 22:10 ` Steve Litt
2019-12-21 11:49 ` Jan Braun
2019-12-04 12:15 ` Jonathan de Boyne Pollard
2019-12-04 21:02 ` Laurent Bercot
2019-12-04 1:30 ` s6 usability (was: runit patches to fix compiler warnings on RHEL 7) Casper Ti. Vector
2019-12-21 9:26 ` s6 usability Jan Braun
2019-12-21 18:36 ` Guillermo
2019-12-21 21:19 ` Colin Booth
2019-12-22 1:05 ` Jan Braun [this message]
2019-12-22 8:30 ` Colin Booth
2019-12-21 23:46 ` Laurent Bercot
2019-12-22 5:53 ` Jan Braun
2019-12-22 20:33 ` Steve Litt
2019-12-22 23:20 ` Laurent Bercot
2019-12-23 1:28 ` Oliver Schad
2019-12-23 9:14 ` Laurent Bercot
2019-12-23 10:15 ` Jonathan de Boyne Pollard
2019-12-24 0:18 ` Oliver Schad
2019-12-23 1:57 ` Steve Litt
2019-12-23 9:00 ` Laurent Bercot
2019-12-22 23:47 ` Dewayne Geraghty
2019-12-04 11:36 ` runit patches to fix compiler warnings on RHEL 7 Jonathan de Boyne Pollard
2019-12-04 16:40 ` J. Lewis Muir
2019-12-04 20:48 ` Laurent Bercot
2019-12-04 21:32 ` J. Lewis Muir
2019-12-04 21:06 ` Steve Litt
2019-12-04 21:50 ` Laurent Bercot
[not found] ` <20191205132736.7f501460@puter>
2019-12-08 19:10 ` Laurent Bercot
2019-12-02 17:57 ` J. Lewis Muir
2019-12-02 21:06 ` J. Lewis Muir
2019-12-02 22:22 ` Laurent Bercot
2019-12-02 21:58 ` Laurent Bercot
2019-12-03 10:57 ` Benjamin Franksen
2019-12-04 10:43 ` Jonathan de Boyne Pollard
2019-12-02 17:13 ` J. Lewis Muir
2019-12-04 11:13 ` Jonathan de Boyne Pollard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191222010514.sklyo7fmo7ftpcxt@klumpi.ignorelist.com \
--to=janbraun@gmx.de \
--cc=colin@heliocat.net \
--cc=ska-supervision@skarnet.org \
--cc=supervision@list.skarnet.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).