cvs commit: ALFS/nALFS/src init.c init.h nalfs.c

Neven Has haski at sezampro.yu
Wed Nov 5 12:41:56 PST 2003

On Wed, Nov 05, 2003 at 01:27:43PM -0700, Kevin P. Fleming wrote:
> Neven Has wrote:
> >"nALFS --rcfile package.xml" tries to read package.xml as a rc file,
> >instead of exiting with an error (No profiles specified).
> Hmm, that's a tough one to fix. I don't know how we could stop it trying to 
> read it as an rc file, without putting some restriction on rc file names or 
> something. Really, if the user wants to specify invalid parameter 
> combinations, they will do it no matter what the program tries to do to 
> deal with it.

Actually, it's the number of parameters that's wrong.

In read_command_line_options(), we shouldn't parse_rc_file() as soon
as we see the option, but remember the file instead, as we do with
other options.  Then simply parse it elsewhere, after "Check for
specified profiles" (and outside of read_command_line_options()).

> >"nALFS --help", "nALFS --version" don't do what's expected when rc
> >file is broken -- nALFS shouldn't read it at all, but display default
> >values in --help.
> Yes, will fix that. Will have to scan directly for --help/--version and 
> just ignore all other command line parameters, I would think.

No need for that, if we do it as above.  I would like to avoid any
extra parsing/searching of command line options, and simply handle all
that work in read_command_line_options() alone.

> >I'm still not sure about the best way of doing that.  Maybe by adding
> >a flag for each option, that will indicate whether it has been
> >changed... (comparing the value with the default won't do
> >unfortunately).
> Something like that, yes. Maybe a priority level, so:
> /etc/nALFSrc is priority 0
> "default" nALFSrc is priority 1
> --rcfile on the command line is priority 2
> command-line parms are priority 3
> Then it doesn't matter what order they are read in, just don't
> overwrite an existing value with a lower-priority value.

Yeah, priority value would be good.  I like that.

> A problem with that is currently option values for boolean and numeric 
> options are changed directly, not going through any set_X_option functions. 
> I was planning on changing that anyway, to be able to enforce validation 
> any time an option value is changed, so maybe this will be another reason 
> to do that.

Maybe we should forget Friday? :)  I'd like a few feature-freeze-days,
so we can just stare at the code and do nothing.  Incredible how much
is that useful (not only for nerves, but for spotting bugs as well).


More information about the alfs-log mailing list