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
On 26/10/2019 4:06 am, Guillermo wrote:
...
> Let me guess: the value of PATH is
> /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin,
> execline's chain loading umask is in /usr/local/bin, and FreeBSD
> happens to have an 'umask' shell script in /usr/bin. If that is
> correct, then
El vie., 25 oct. 2019 a las 5:22, Dewayne Geraghty escribió:
>
> Results for umask
> rm -f /tmp/t1 ; /usr/local/bin/execlineb -Pc 'redirfd -w 1 /tmp/t1 umask
> 037 echo hello' ; echo $? ; ls -l /tmp/t1
> [...]
> I've placed the ktrace's dumpfile in txt format so its readable for you at
>
Laurent, I've embedded responses:
On 24/10/2019 10:58 am, Laurent Bercot wrote:
>> My initial attempt
>>
>> #!/usr/local/bin/execlineb -P
>> s6-setuidgid uucp
>> redirfd -r 0 /services/ntp/fifo
>> umask 037
>> /usr/local/bin/s6-log -b n14 r7000 s10 S300 !"/usr/bin/xz -7q"
>> /var/log/ntpd
