> > Don't you consider symlinks as a kind of a hack around a basic flaw in the
> > configuration process?
>
> Elsewhere you stated that a certain aspect of the current situation is not
> very Unix-like. Well, symlinks are very Unix-like. They have been
> invented exactly for the purpose of sharing files for several purposes,
> while maintaining the identity of the "original" (else use hard links).
> They are not hacks, they can be nested and used recursively, they are
> self-documenting and they don't prevent you from adding your own
> documentation either. I don't want to be adding a new feature anytime
> someone doesn't like the tools the operating system already provides.
Let me throw in my ideas. Clearly, symlinks work, and clearly, a special
-C flag is more documenting than the symlinks.
My issue is, should we add yet another configuration flag to an already
flag-heavy command and let people use symlinks for special cases, or
should we add the flag. I guess the question is whether the option will
be used by enough people that the extra flag is worth the added
complexity.
There is added complexity. Every flag is evaluated by users to
determine if the flag is of any use to them, even if they don't use it.
I wonder if we should go one step further. Should we be specifying the
config file on the command line _rather_ than the data directory. We
could then specify the data directory location in the config file. That
seems like the direction we should be headed in, though I am not sure it
is worth the added headache of the switch.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026