Profile include support, round 2

[Ken Raeburn]

On Aug 24, 2010, at 08:18, ghudson at MIT.EDU wrote:
> I've rewritten the profile include project page, based primarily on
> feedback from Russ.

Under "interface design" it says "line[s] from the file are parsed as if they belonged to the original profile file".  Does that mean the included file's contents are effectively substituted in the middle of the including file, and parser state like the current section is oblivious to the multiple-file structure?  (So, including a file that says "foo = bar" causes that entry to be added to the current section, without needing a new top-level section spec, and including a file that says only "[wombat]" causes the next line of the including file to be entered in the "wombat" top-level section, and not the section that preceding lines were in?  If so, I'd label it good practice to always set the top-level section in the included file, and immediately after the include directive in the including file, to deal with these.  But for now, I'm just asking for clarification of the semantics.)

Are include directives in the included files processed recursively?

I think I'd add "-" to the list of characters to accept in filenames in a directory.  I'd anticipate $dir/krb5.conf.${packageName} or just $dir/${packageName} to be used in some cases, and I'd expect "-" to be used there a lot.  Or is "foo-" used as a backup file name a lot?

Ignoring the problem of relative pathnames is a bad idea.  If nothing else, you should document a recommendation against using relative paths in production environments.  (And if you think you might want to change the interpretation later, document that potential future incompatibility too.)

Ken