On Wed, Sep 13, 2023 at 12:00:51AM +0200, Alexandre Detiste wrote:
> I think that the risk that some user start by themselves moving around
> some programs
> around the PATH directories and expect nothing to break is quiet moot.
I don't. Users love putting stuff in /usr/local/{,s}bin. And then
removing it. That's kinda what it's there for. Not a huge ask to have
"@daily nodejs pee poo" behave correctly regardless of whether I
recently (un)installed upstream node (not a hypothetical scenario).> And I'm pretty sure I/we already broke some scripts everywhere without > caring too much. > I do was using boot_daily directly from /lib/systemd/ ; > that broke when the scripts were moved to /usr/libexec: > https://www.mail-archive.com/debian-devel@lists.debian.org/msg377086.html > > This guy using mail_on_failure has certainly some .service to adapt now: > https://bugs.launchpad.net/ubuntu/+source/systemd-cron/+bug/1583743 Don't use random undocumented internals challenge 2020 (difficulty degree: impossible). > But on the other hand having this exact path of the launched program > in the generated .service make it much easier to debug. To debug when it inevitably breaks because it's hard-coded instead of being behind a path lookup like was written ‒ certainly. If only we could put a big banner somewhere with the full job definition in systemd! Then we wouldn't need to resort to this aid; alas. And this is moot anyway since we only inline single-word programs, so we could only do this transformation for single-word programs. I cannot imagine anything that would be affected if we do /that/, since there aren't any programs that are useful when you run them with no arguments from a crontab /and/ you're managing them like that. I.e. prefix if(auto pgm = this->which(this->command[0]); pgm && *pgm != this->command[0]) { with if(this->command.size() == 1) and you get maximum optimisation and usefulness without ‒ realistically ‒ any of the oddities. > > IMO we should trim the whole function ... KSH_SHELLS > The ~/ path expansion was requested and provided by wavexx > and is a really nice feature and will stay. Yes, leave /that/ in, and axe everything after that imo. That's my idyllic take. > > needless magic (like this) > generators are mostly built on magic by design; > if people would not want automagic solution > they would had been writing .service / .timer pairs > for ten years already. They want to run the shell program they wrote where a >/dev/null is the same as a>/dev/null is the same as a> /dev/null is the same as a > /dev/null; is the same as a > /dev/null && : is the same as… Just because it's driving a generator instead of a persistent daemon doesn't make the configuration any less configurationy. (This also means that a>/dev/null may mean four different things: '/bin/a>/dev/null' /bin/sh -c 'a>/dev/null' /bin/a /bin/sh -c 'a' but. y'know. No-one calls programs this.)
signature.asc
Description: PGP signature
