On Thu, Mar 13, 2008 at 05:55:36PM +0100, Alain Guibert wrote:
> On Tuesday, March 11, 2008 at 13:25:59 +0100, Karel Zak wrote:
> > It's always bad thing when you can't change a setting (e.g. paths)
> > without recompilation.
>
> Very true. But the alternative is not option or nothing, but option or
> env var. I think that an ADJTIME_PATH to override the default adjfile
> is more adapted to this case, more handy for the minority needing it.
I really don't like this ADJTIME_PATH idea, environment variables
suck...
On Thu, Mar 13, 2008 at 01:42:11PM -0400, Mike Frysinger wrote:
> On Thursday 13 March 2008, Alain Guibert wrote:
> > On Tuesday, March 11, 2008 at 8:22:15 -0400, Mike Frysinger wrote:
> > > On Tuesday 11 March 2008, Alain Guibert wrote:
> > >> So a command line option to select a file doesn't make much sense,
> > >> and would be prone to mismatches between various scripts, or be
> > >> forgotten when the user invokes hwclock by hand.
> > >
> > > global configuration files handle this.
> >
> > And for those global configuration files, the best way to give one
> > adjfile to all hwclock calls is probably environment, isn't it?
>
> config files generally setup options to pass, not environment variables. if
> the option to control the location is available at runtime, providing an env
> var back door rather than command line is just awkward. there is no sense in
> not simply providing a cmd line option like everything else in that case.
I think command line option and a global config file (e.g /etc/hwclock)
are a good idea.
It seems that we can use the config file for almost all hwclock
options -- it could be an attractive solution for people with exotic/old
HW who need special setting.
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
