Raul Miller <[EMAIL PROTECTED]> writes: > Andreas Degert <[EMAIL PROTECTED]> wrote: > > please don't answer too quickly; if you think about it a second > > (in the context of the thread) you will realize that I wrote about > > syntactically and semantically correct config files that are too > > complex for the parser. > > That shouldn't matter for context free grammars. If the grammar > isn't context free you're dealing with something like unrestricted > perl, not a config file.
That is not the point; of course just the parsing, the syntactical portion, is rather easy. Else, how should a program like samba parse it's config files? Even if it's a complex embedded language, by definition its syntax can be parsed, and if it's for a program you even have the source for it. The problem lies in understanding the semantics from the users point of view, so that it can be presented to the user in a reasonable form. This is what the parser of a configuration program has to achieve. > > For, samba, a config file overwriting some global setting indirectly > > with the line > > > > include = /etc/smb.conf.%m > > > > occurring later in the config file (%m expands into the client machine > > name) is already tough for the parser (and the ui displaying the > > data). > > You mean a non-global override of a global default? It's both in the global section of the config file; you can use it to set a default log level for all clients, but a different log level for specific clients (just one example). It's "local" with respect to a single client; just can also use %a instead of %m, which will expand to the architecture of the client machine, or %R for the protocol level client and server have agreed upon. > > For a UI you need an area for defaults, and you need to be able to > enter specifics (specific file system areas, specific printers). Under > a specific file system entry you need to be able to represent the > defaults and you need to be able to represent overriding them. You can special-case it for my example, and I'll just make my example a bit different or more complex. For example, as the user gets fed up with different log level for his 1001 clients, he just puts a log level = 1 _after_ the line with the include statement. Perfectly valid. Samba will run with log level 1 for all clients, though other client-specific settings will be retained. And the nice thing, when the user comments out this additional line, he has the old client-specific log-levels again. How do you make a config program understand that and present it to the user? One goal was that no info shall be lost, so it would be illegal if the config program zapped the config lines that are globally overridden. If you modify a configuration that was read from a definition which is spread over several files, into which file do you put the new/changed configuration statement? IMHO, if you want to handle all these cases, the configuration program gets more and more complex, also for the user, and in the end it's worse than just giving the user an editor and a manpage. A configuration program should guide the user through the configuration, and prevent him from defining silly configurations, even if they are formally correct. You have to draw a line somewhere, and this means your configuration program will have to reject reading some config files that are perfectly valid and meaningful for the special case of some user. OTOH, you will prevent a lot of users from screwing up their configuration. I took the example of samba config files, because at the first look they seem to be very simple (it's the windows ini-file syntax, with sections and assignments to keywords). But the simple existence of these include statements makes it much more involved. I haven't found a configuration program which handles samba includes well. If you look at config files like .emacs or /etc/profile where it's apparent that they use a structured language, it's much more clear that a configuration program can't grok each possible config file the user can write with an editor. ciao Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
