supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
From: "Laurent Bercot" <ska-supervision@skarnet.org>
To: Supervision <supervision@list.skarnet.org>
Subject: Re: s6-log can create current with 640?
Date: Tue, 29 Oct 2019 08:53:10 +0000	[thread overview]
Message-ID: <emea8365cd-7671-4daa-889b-c0c38ca3176a@elzian> (raw)
In-Reply-To: <a8fbd02e-0265-3d59-89d1-81048665693c@ntlworld.com>

>Not quite.  People find uses for these things, and as the SUS rationale points out, for every potentially useless external equivalent of a (non-special) built-in command someone has come up with an arcane actual use for it.  Even "cd".

Oh, definitely. And if my bathtub had a built-in trumpet, I could
certainly find a use for it, too; but that doesn't mean it would make
sense, no matter whether or not it's written in an official 
specification
for bathtubs.


>The POSIX model is therefore that all non-special built-ins are also available as executables; or, rather, that all of the standard utilities that are not special built-ins are simply *available* (via execvp(), find -exec, env, and *all of the other* ways that standard utilities can be invoked), and whether they are built-in or not, to a shell or otherwise, is an implementation detail as far as actually invoking the utility is concerned.

And I have no qualms about it for builtins that do something else than
just change the process state. But for a builtin that's supposed to only
change the process state, and whose use as an external program is
marginal at the very best, that model is terrible: it tries to make the
presence or absence of a shell undetectable (which it can never be), and
the consequences of that attempt leak outside of the legitimate domain
of the shell, and Dewayne's issue with umask is an illustration of this.

--
Laurent



      parent reply	other threads:[~2019-10-29  8:53 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-23  2:27 Dewayne Geraghty
2019-10-23  4:53 ` Colin Booth
2019-10-23  5:39   ` Dewayne Geraghty
2019-10-23  7:15 ` Jonathan de Boyne Pollard
2019-10-23 23:03   ` Dewayne Geraghty
2019-10-23 23:58     ` Laurent Bercot
2019-10-25  8:20       ` Dewayne Geraghty
2019-10-25 17:06         ` Guillermo
2019-10-26  1:52           ` Dewayne Geraghty
2019-10-26  5:27             ` Laurent Bercot
2019-10-26  7:16               ` Dewayne Geraghty
2019-10-26 13:08                 ` Laurent Bercot
2019-10-29  7:28               ` Jonathan de Boyne Pollard
     [not found]               ` <a8fbd02e-0265-3d59-89d1-81048665693c@ntlworld.com>
2019-10-29  8:53                 ` Laurent Bercot [this message]

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=emea8365cd-7671-4daa-889b-c0c38ca3176a@elzian \
    --to=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).