When providing code to another, it appears to be good practice to remove all elevation-specific code — that is, provide apt update rather than sudo apt update (or su -c 'apt update'). However, this causes all kinds of problems for those new to UNIX-based permission elevation — I and many others I have met used to merely run everything as the superuser using the aforementioned utilities.
Additionally, when invoking certain commands programmatically, superuser elevation shall be necessary on some systems, but not on others. This means that including the permission elevator can break configurations on some systems, because things shall begin to be owned by the superuser when they shouldn't be. flatpak is an example of some of this (except the configuration corruption) — 50% of the installations I've used necessitated elevation to invoke most of its commands, the other 50% didn't, by default.
Considering that UAC elevation on Windows 7+ appears to work incredibly well even in edge cases in my experience with it, I am seriously surprised that no comprehensive methods of remediating this issue appear to exist.
Consequently, I ask whether anyone knows of any methods of programmatically determining whether a command necessitates user elevation to invoke it. I am aware that switching users when invoking certain commands can cause its behaviour to affect that user, but in those instances, I cannot imagine that the users able to invoke the command would be restricted (lest it be rendered useless).
https://unix.stackexchange.com/search?q=determine+whether+superuser+elevation+required returns nothing, and although how to determine through code if command needs root elevation? and How to check if the "sudo" permission will be necessary to run a command? appear as if they're asking what I want know, the few responses available at both appear to be focussed upon shell script code to sidestep the issue rather than providing language-agnostic solutions.
aptcommand you use as an example is executed via the shell, so "shell script code" seems appropriate to me. – Kusalananda Mar 12 '24 at 14:32$?) too wonky? For example,apt updatereturns 100 when executed with insufficient permission, whereasaptand other programs return 0 on success. – Christopher Mar 12 '24 at 14:38.shcode follows the POSIX specification. For instance, try using/usr/bin/env -S shorbashin POSIX compatibility mode — not all of its features way work in yourbashfiles. I mentioned this due to the usage of comparator operators in the aforementioned answers. – RokeJulianLockhart Mar 12 '24 at 14:44-Soption toenvdoes not seem to be a POSIX option, is it something that Linux adds? (I'm not ordinarily a Linux user; Busyboxenvdoes not understand-S) – Kusalananda Mar 12 '24 at 15:07enveach has a-Soption, which splits the string specified after-Sin the shebang into multiple strings to pass as arguments toenv. But... I don't see how/usr/bin/env -S shis any different than/usr/bin/env sh. You? – Christopher Mar 12 '24 at 15:42env -S). No, there is no difference between usingenvwith or without-Sin that case, apart from being non-portable with-S. – Kusalananda Mar 12 '24 at 16:10-Sis not POSIX. Thank you. Yes, coreutils and MacOS is a much better description. – Christopher Mar 12 '24 at 16:51-Sbecause it means that when I'm using a shebang with multiple space-delimited arguments, I don't forget it. It's also a useful way to ensure that they are solely ever invoked on a recent machine using the GNU core utilities. – RokeJulianLockhart Mar 12 '24 at 20:23