Re[2]: Silent or move to /dev/null alsactl restore out

2024-11-30 Thread Laurent Bercot




`fdmove -c 2 1` is equivalent to shell `2>&1`. You're looking for `redirfd
-w 2 /dev/null`.


 ... and *now* I understand what Luis wanted. Now that you're laying
it out explicitly, it was simple, and I feel dumb. Sorry.

--
 Laurent



Re[2]: Silent or move to /dev/null alsactl restore out

2024-11-30 Thread Laurent Bercot




i feel like this might possibly be a reason why a number of people assume that 
_all_ s6-ecosystem scripts have to be execline scripts.


 I don't think it is the case, no. The myth started well before s6-rc
was a thing. From the first days of s6, people assumed that, despite
the documentation explicitly saying the opposite; this has nothing to
do with execline's use in s6-rc.



However, while it's true that in both s6 and s6-rc, use of execline is not 
_ultimately_ required, in the s6-rc `up` context, one _does_ have to at least 
use execline to call the preferred interpreter with the relevant script.


 The point of hardcoding execline here is that I need a middle ground
between "force up/down to be a path to an external script", which is
not flexible wrt e.g. existing sysvinit/openrc scripts you way want to
call with "start" and "stop" arguments, and "make up/down full
scripts/executable files", which requires embedding scripts/executables
in the compiled db, which, no.

 And that's *exactly* what execlineb is for.
 The idea is for people to write
echo "/path/to/script start" > $oneshot/up
without wondering too much about it, and *without* needing to get lost
in the details of execline syntax. But obviously, I suck at predicting
user behaviour, and people always end up wanting to be too smart and
tying their brains in knots about incredibly simple stuff, so, whatever.

--
 Laurent