Re: s6-log can create current with 640?

From: Dewayne Geraghty <>
Date: Sat, 26 Oct 2019 18:16:28 +1100

Hi Laurent, Answers embedded

On 26/10/2019 4:27 pm, Laurent Bercot wrote:
>> I'd mistakenly assumed execlineb knew where its friends were; though in
>> hindsight its a bit much to assume that execlineb internally changes the
>> PATH.
> 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.

I can only shed a ray of light, though this /usr/bin/umask has been
around for some time. I fired up an old FreeBSD 9.2 system that has it.
Content being:

# $FreeBSD: stable/9/usr.bin/alias/ 151635 2005-10-24
22:32:19Z cperciva $
# This file is in the public domain.
builtin ${0##*/} ${1+"$_at_"}

which is the same as 12.1. Why? I can only refer to src logs:

r151635 | cperciva | 2005-10-25 08:32:19 +1000 (Tue, 25 Oct 2005) | 10 lines

Use the "builtin" shell function to make sure that the requested
command is handled as a shell function. This avoids the following
peculiar behaviour when /usr/bin is on a case-insensitive filesystem:
    # READ foo
(... long pause, depending upon the amount of swap space available ...)
    sh: Resource temporarily unavailable.

r100200 | wollman | 2002-07-17 08:16:05 +1000 (Wed, 17 Jul 2002) | 5 lines

A little bit more thought has resulted in a generic script which can
implement any of the useless POSIX-required ``regular shell builtin''
utilities, saving one frag and one inode each. The script moves to
usr.bin/alias which is alphabetically the first of these commands.


the last entry before the cvs logs were transferred to svn.

Examining the Makefile/usr/src/usr.bin/alias/Makefile
# $FreeBSD: stable/12/usr.bin/alias/Makefile 284255 2015-06-11 04:22:17Z
sjg $

LINKS= ${BINDIR}/alias ${BINDIR}/bg \
        ${BINDIR}/alias ${BINDIR}/cd \
        ${BINDIR}/alias ${BINDIR}/command \
        ${BINDIR}/alias ${BINDIR}/fc \
        ${BINDIR}/alias ${BINDIR}/fg \
        ${BINDIR}/alias ${BINDIR}/getopts \
        ${BINDIR}/alias ${BINDIR}/hash \
        ${BINDIR}/alias ${BINDIR}/jobs \
        ${BINDIR}/alias ${BINDIR}/read \
        ${BINDIR}/alias ${BINDIR}/type \
        ${BINDIR}/alias ${BINDIR}/ulimit \
        ${BINDIR}/alias ${BINDIR}/umask \
        ${BINDIR}/alias ${BINDIR}/unalias \
        ${BINDIR}/alias ${BINDIR}/wait

and yes they exist in /usr/bin/

>From tcsh
# which cd
cd: shell built-in command.

>From sh
# which echo

Ok - that's done my head in.
>> Unfortunately it seems that the path can't be set within execlineb
>> context.
> Of course it can. What's happening is that both export and envfile
> set the PATH *on execution of the next command*, so the command that's
> right after them will still be searched with the old PATH. In other words:
> "export PATH /usr/local/bin umask 033 echo blah" will not work, because
> umask will still be searched for in the old PATH (but echo would be
> searched in the new PATH), but
> "export PATH /usr/local/bin exec umask 033 echo blah" will work, because
> exec is searched in the old PATH and umask is searched in the new PATH.
> (exec is an execline nop that can be useful in those cases, if you
> don't have another command to put between the export PATH and the
> command you need to search in the new PATH.)

Thank-you, the explanation helps. I guess through bad experiences with
(non-execline) exec, I avoid it unless I really do want to transfer
control to it.

I think with this example
# rm -v /tmp/t1 ; setenv PATH
/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin ; execlineb -Pc 'importas
op PATH emptyenv export PATH /usr/local/bin:$op exec umask 002 redirfd
-w 1 /tmp/t1 echo blah4' ; /bin/ls -l t1 ; cat /tmp/t1
-rw-rw-r-- 1 root wheel 6 26 Oct 18:02 t1

Due to the above discussion around umask, I will have to consider either
adding to my execline scripts :(
importas op PATH
export PATH /usr/local/bin:$op

or explicit paths as needed.

Thank-you to the contributors for your patience.
Received on Sat Oct 26 2019 - 07:16:28 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:44:19 UTC