Date: Thu, 19 May 2022 10:40:35 +0000 From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 263675] [NEW PORT] dns/acme-dns Message-ID: <bug-263675-7788-FNvDWlywfa@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-263675-7788@https.bugs.freebsd.org/bugzilla/> References: <bug-263675-7788@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D263675 --- Comment #4 from Stefan E=C3=9Fer <se@FreeBSD.org> --- No, libexec is not for shared libraries, it is the place for binaries that = are not typically started from an interactive shell (but rather as a service, f= rom inetd, or invoked as a sub-process that is not run on its own). The major difference is that commands in libexec are not in any shell path = by default, you have to invoke them with a full path (or temporarily add libex= ec to the PATH in the current process environment). Since this is a command that is waiting for requests as a background task started as a service via etc/rc.d, I'd think that it should be placed in libexec and the full path should be patched into the rc file. This will not be necessary for a command in sbin, but then it will clutter = the list of commands presented to an administrator that uses name completion in= a shell, for example. And I'd try to avoid that for commands that are not use= d in interactive shells. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-263675-7788-FNvDWlywfa>