Re: s6-log can create current with 640?

[Laurent Bercot]

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

Re: s6-log can create current with 640?

[Jonathan de Boyne Pollard]

Laurent Bercot:
The real question is, why is there a "umask" binary that's not the one 
from execline? Non-chainloading non-builtin umask is nonsense, just 
like non-chainloading non-builtin cd. 


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".


* 
https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xcu_chap01.html#tag_23_01_07


* https://unix.stackexchange.com/q/50058/5132

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.  (Very few shells truly conform to this, but the 
Watanabe shell largely does in its non-native mode.)


* https://unix.stackexchange.com/q/347188/5132

* https://unix.stackexchange.com/q/496259/5132

nosh, not being a shell, is not bound by this.  Its built-ins are found 
before a PATH search is enacted.  So it actually does what M. Geraghty 
mistakenly thought execline was doing.  It finds its own built-ins in 
preference to finding external commands; so invoking "umask" (without 
directory name prefix) within a nosh script will always invoke the 
built-in chain-loading one, irrespective of PATH. (Several of the 
non-conformant shells do this, too, giving their built-ins unequivocal 
precedence over a PATH search.  Some even document this behaviour.  But 
it is not standard-conformant for a shell.)


* https://unix.stackexchange.com/a/496377/5132

* http://jdebp.uk./Softwares/nosh/guide/commands/exec.xml

execline always searches PATH.  It does not have built-ins like nosh or 
shells, in the first place.  There's a quirk about when changes to PATH 
take effect, and it does not quite have the POSIX semantics for when 
PATH is not set, but other than that it actually has the POSIX model 
behaviour: Commands are located using PATH, and what command one invokes 
by the name "umask" is entirely determined by what PATH lists.


* https://unix.stackexchange.com/a/448799/5132