Wow, I must have missed that in the docs.
Thanks!
A system wide config might be worth doing, but this takes care of
everything I need.
Sorry for the noise.
On Thu, 11 Apr 2002, Charles Reitzel wrote:
> Just to be clear about what Tidy already does, by default build (i.e. in
> all the binaries found on http://tidy.sf.net), the order is this:
>
> 1) Load config file named in HTML_TIDY environment variable - if it exists.
> 2) Load config file named on command line
>
> There are two build-time options related to loading config files. These
> options may be used separately or together.
>
> A) Home directory - SUPPORT_GETPWNAM
>
> If you un-comment the line #defining SUPPORT_GETPWNAM in platform.h, then
> the processing is as follows:
>
> 1) If it exists, load config file named in HTML_TIDY environment variable.
> If not, load the file named "~/.tidyrc", i.e. in the current logon ID's
> home directory.
>
> 2) Load config file named on command line
>
>
> B) Fixed config file - CONFIG_FILE
>
> If you define the C macro CONFIG_FILE at build time (anywhere, e.g.
> -D CONFIG_FILE=abc on make command line is sufficient), Tidy will attempt
> to load this config file _prior_ to loading any other config file.
>
> So, without changing source code, you can build a local version of tidy
> that looks for "~/tidyrc" or "/etc/.tidyrc" or "joebob".
>
> =============================================================================
>
> Btw, support for non-"dot" filenames is a holdover from the bad, old DOS
> 8.3 days. Yes, I know a certain CD-ROM format still requires 8.3 names,
> but are you going to put a Tidy config file onto this equally antiquated
> format? If you must support a DOS/Windows-style file name, my vote is
> tidy.rc. At least this file extension can be associated with a text editor
> for easy access from the GUI. Adding this new variation to your scheme
> would make it way over-complicated.
>
> So, how about a compromise? The idea of looking in the current directory
> is a good idea. The other thing that we could easily do is make the config
> file base name a macro with a default value of CONFIG_BASE=.tidyrc This
> macro could be redefined on the build command line to "tidyrc", "tidy.rc"
> or "joebob".
>
> The search path, then, would be:
>
> 1) ./$CONFIG_BASE
> 2) $HTML_TIDY
>
> #ifdef SUPPORT_GETPWNAM
> 3) ~/$CONFIG_BASE
> #endif
>
> The first item found would be used. Any others would be ignored. The
> $CONFIG_FILE and command line files may still be processed.
>
> This structure isn't ideal, but it preserves compatibility with the
> existing behavior so we don't give anyone a surprise.
>
> Thoughts?
>
> take it easy,
> Charlie
>
>
>
> At 07:12 PM 4/9/2002 -0400, Dale J. Chatham wrote:
> >On Wed, 10 Apr 2002, Klaus Johannes Rusch wrote:
> >
> > > Dale
> > >
> > > > On the UNIX side, I think you should consider default locations for
> > > > configuration files. I would think that all of the following should be
> > > > searched, with the first hit of a confirmed file specifying the file:
> > > >
> > > > `pwd`/tidyrc
> > > > `pwd`/.tidyrc
> > > > Environmnet variable
> > > > ~/.tidyrc
> > > > ~/etc/tidyrc
> > > > /etc/tidyrc
> > > >
> > > > This conforms to UNIX conventions and would allow various levels of
> > > > standards for the way HTML should look.
> > >
> > > this may be on the requested feature list already, otherwise may I
> > suggest you
> > > add this to under http://tidy.sf.net for tracking purposes and to avoid
> > > duplication of your work -- certainly would make sense to support
> > common paths
> > > (for Windows and OS/2 probably %DPATH%\.tidyrc could be supported too)
> > >
> > > I would vote for a single filename though, not multiple filenames.
> >
> >The multiple filenames duplicates the rc files for bash, csh, sh. If you
> >go for a single file, please go for ~/.tidyrc The multiple gives a lot of
> >possibilities for localizing configuration, though.
> >
> > >
> > >
> >
> >--
>
--