Once upon a time, Matthew Garrett <mjg59@xxxxxxxxxxxxx> said: > The suggestion isn't that having the options is wrong Well, that's what you said before (conveniently snipped from your reply). You compared CLI args/env vars to the BKL as something to be eliminated; specifically, you said (and I quoted): > In this case there are sound > technical arguments against configuration by command line argument or > environment variable You have still failed to enumerate even one of the "sound technical arguments". > it's that having > them as the primary means of configuration is poor design. If your > entire configuration takes the form of a shell script that constructs a > set of command line options then you've increased fragility for no > benefit. Having a proper configuration file and allowing admins to > override specific aspects of that from the command line isn't a problem. You are moving the target (to a worst-case example) and still not winning your argument. This is more than theoretical to me; a small package I maintain is one example of a command-line configured daemon. The shmpps daemon is a tiny little daemon that reads a timing pulse-per-second and updates a shared memory segment. It uses a few command line arguments to set the source port/type and shared memory segment destination; right now, that is done for the init script by a file in /etc/sysconfig. This is a small, light-weight daemon, and doesn't need a configuration file parser. This is a valid way that Unix daemons have run for decades, and you are saying that should be removed. I guess every small daemon now needs to include its own config file parser, replacing the already-existing getopt() call? How is this "better"? -- Chris Adams <cmadams@xxxxxxxxxx> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
