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,
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
A little bit more thought has resulted in a generic script which can
implement any of the useless POSIX-required ``regular shell builtin''
Yeah, so it's another one of those functions that only make sense as
shell builtins but that are still also implemented as external commands.
Beats me why
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
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
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
Hi Dewayne,
- Is there a reason why you're using a manually created fifo instead
of the built-in
Thanks Jonathon. Both attempts were within the execlineb context, so I
assume that umask was correctly employed ;). I tried
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
Dewayne Geraghty:
I did try umask 037 but that just broke the pipe.
That was probably because you were using the wrong umask tool. It has
to be the chain-loading one in a nosh or an execlineb script.
% cat /var/sv/deluged/service/run
#!/bin/nosh
#Deluge BitTorrent client
envuidgid --
Thank-you, Colin.
My brain turned to mush integrating logging with fifo queues across
multiple jails (aka very lightweight VMs) and disjoint users (userA
writes, userB reads). Unfortunately they're across various jailed
systems, so the s6 fifo tools aren't applicable. I appreciate your
advice,
On Wed, Oct 23, 2019 at 01:27:24PM +1100, Dewayne Geraghty wrote:
> Is there any way to tell s6-log to set the mode to ./current to
> something other than 644? 640 is preferred?
>
> For example: I write to the logdir /var/log/httpd/error which has privs:
>
> /var/log/http
> drwx-- 2 uucp
13 matches
Mail list logo
