I was wondering if we have reached some sort of consesus on Linuxconf.
The points that I see are
*Linuxconf can't lose any info.
--This might mean that Linuxconf will error out if it can't parse the file,
if you've made private changes to it. That's the tradeoff, you take a
Shaya Potter <[EMAIL PROTECTED]> writes:
> I was wondering if we have reached some sort of consesus on Linuxconf.
>
> The points that I see are
>
> *Linuxconf can't lose any info.
> --This might mean that Linuxconf will error out if it can't parse the file,
&
At 03:54 PM 6/3/98 +0200, Andreas Degert wrote:
>Shaya Potter <[EMAIL PROTECTED]> writes:
>
>> I was wondering if we have reached some sort of consesus on Linuxconf.
>>
>> The points that I see are
>>
>> *Linuxconf can't lose any info.
>>
Shaya Potter <[EMAIL PROTECTED]> writes:
> >> --This might mean that Linuxconf will error out if it can't parse the file,
> >> if you've made private changes to it. That's the tradeoff, you take a risk
> >> that you won't be able to use linuxconf if you privately edit the file. We
> >> will work
Andreas Degert <[EMAIL PROTECTED]> wrote:
> No, i meant you can't prevent the parser to error out on some edited
> config files, not that it will happen with every edited config file.
config files which are broken should be treated as error conditions.
For example, if you put this email message i
Raul Miller <[EMAIL PROTECTED]> writes:
> Andreas Degert <[EMAIL PROTECTED]> wrote:
> > No, i meant you can't prevent the parser to error out on some edited
> > config files, not that it will happen with every edited config file.
>
> config files which are broken should be treated as error condit
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 co
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
> > co
Andreas Degert <[EMAIL PROTECTED]> wrote:
> 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
On 4 Jun 1998, Andreas Degert wrote:
> 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.
It's also
Previously G John Lapeyre wrote:
> It's also not uncommon to see config files which just contain perl
> code. (Majordomo comes to mind) . Probably python programs do this too.
But nobody said all conffiles should be managed by linuxconfig (or any
configuration system for that matter). A lo
> "Wichert" == Wichert Akkerman <[EMAIL PROTECTED]> writes:
Wichert> [...] most files in /etc/init.d are marked as
Wichert> conffiles. But only a couple of them actually contain
Wichert> configuration-info.
Have yous seen the "/etc/sysconfig" setup in Red Hat 5.0? I wonder
if w
12 matches
Mail list logo
