[2019-01-27 18:56] Andras Korn <korn-debb...@elan.rulez.org>
> > Complicated. And depends on $0 trickery. We, at sysvinit team, had
> > problems with $0 trickery.
>
> How is this trickery? We're just obtaining the name of the script being
> executed, and its path.
Relying on $0 makes me uneasy. Because one day I may want to re-use this
code, but feed it another $0. No, it is not theoretical issue.
> > What is so bad about cluttering environment of daemon?
>
> Normally you'd want to avoid passing unnecessary environment variables to
> daemons. Maybe they'll affect its operation in some way; maybe they'll
> affect a child process of the daemon that inherits them. It's relying on
> undefined behaviour.
I do not buy this argument. For ages we started daemons with
/etc/init.d/{foo} scripts from root shell (and even with sudo), with all
kind of environment variables, including rather nasty ones, like GREP or
LESS, and we are still fine.
But probably executing services with `env -0' is good idea, thank you.
> > > (But then /etc/default/foo would have to take precedence over sv/foo/conf,
> > > because the /etc/default/foo variables would be lost during the exec since
> > > we want to avoid exporting them.)
> >
> > This too. I want daemontools-style take precedence over sysvinit style.
>
> FWIW, I think the whole thing is creeping featurism,
One extra source of variables, implemented with 3 lines of shell? Well,
your definition of 'featurism' is much stricter then mine.
> but if you think you must do it, I'd prefer it being done sensibly --
> i.e. not depending on undefined behaviour, not leaking environment
> variables. I think this is a stronger argument than personal
> preference (yours or mine).
Sure. But see above.
> > And what if there were no tty on installation time, and after that they
> > appeared? (No idea, why, never dealt with devices without tty.)
>
> That's a pathological hypothetical case; I'd say we wait until it happens,
> and then deal with it. (You might also ask: what about hypothetical systems
> where /dev/tty* devices keep disappearing and reappearing in a rhythm that
> always prevents getty from starting?)
Okay. I buy it. I will unconditionally include this code:
if ! test -c /dev/@TTY@ ; then
rm /etc/service/getty-@TTY@
exit 0
fi
and upload to experimental. Should there be no report of that
pathological case, I will merge these changes into unstable after
Buster. Will it do for you?
--
Note, that I send and fetch email in batch, once every 24 hours.
If matter is urgent, try https://t.me/kaction
--
