On Monday 31 March 2008, Alain Guibert wrote: > > command line options for controlling behavior is the standard > > interface for everything at this level. > > That's not exactly right. Some tools also use env vars. for the ones i can think of, the env vars are secondary to the command line options > > diverging because you're worried about trying to hold the hands of > > sysadmins (who are supposed to know what they're doing) is just > > craziness. > > We have two methods, $ADJTIME_PATH and --adjfile, of comparable > development cost. One works effortlessly in all cases. The other > doesn't, but sometimes requires additional typing. If the sysadmin then > forgets the option or mistypes the filename, then the call gives wrong > results. Worse, it can even lead the following good call to also give > wrong results. > > In the specific hwclock case, --adjfile is functionaly inferior. Some > other tools do well using --options. This fact is not a valid argument > against an env var. Different situations, different best methods. you're assuming the env var is properly propagated all the time which can sometimes be a daunting task. do you put it in /etc/profile and force pollution in all logged in users ? but what about `sudo` which filters environment variables ? and what about non-logged-in shells that get launched and thus dont source the login scripts ? the env var solution is far from being as good as you describe it. i'm not suggesting the command line option is perfect either, just that it fits all existing/expected paradigms for system configuration. -mike
Attachment:
signature.asc
Description: This is a digitally signed message part.
