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

Kevin P. Fleming kpfleming at linuxfromscratch.org
Wed Nov 5 12:27:43 PST 2003


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.

> 
> "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.

> 
> All in all, read_command_line_options() would have to be called before
> reading rc file.  Of course, command line options have to have higher
> priority, so parse_rc_file() has to be able to skip setting some of
> the options already specified on command line.

Exactly, that's where I was headed but didn't get a chance to finish it up this 
morning.

> 
> 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.

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.



More information about the alfs-log mailing list