alter default config file processing #772
Comments
|
I find it easier to talk about a change if there's actual code to talk about. |
|
@ler762 this seems to be an ever changing landscape ;=)) I had warmed to adding a new options, something like Such a non-invasive new option could certainly help with the I could see - But it is a very minimal use case - such Now, if I read this and the code you suggest - which could have been an embedded or attached diff/patch, rather than a PR, but - you seem to want to change the meaning of the And in addition, change the order of the files... put I am not sure I understand why you want/need to potentially break many user configs that could be out there... To change from the ordered additive config way it is now, to an Can you give a use case? thanks... |
|
@geoffmcl my landscape has stayed the same :) I don't like tidy reading the default init files no matter what, so I'm coming at it from the viewpoint of
We can make it two separate issues if you like.
My only question for 1 is do you allow `-no-config`` anywhere on the command line or does it have to be the first option? I don't like positional parameters, so I'd go with anywhere. If you don't do 2 then you have to modify every test script to include
I don't see any reason -no-config should be required to be the first option.
Yes, I want to change the meaning of
Because I like having just one init file and I don't like hidden variables (ie environment variables).
The various mis-behaviors listed in #752 have existed for how long? My feeling is that if people were actually using /etc/tidy.conf and/or ~/.tidyrc these issues would have been raised & fixed long ago. So I'm guessing the potential breakage is small. But this isn't something I care about all that much, so how about we leave it until -no-config & -config discussions are finished? |
|
@ler762 maybe a new option could be say But agree, such a new option is not really necessary... has a minor It seems the #752 That gives us no indication of the usage of But why guess at the potential breakage when it can be avoided? The current additive order of config files is not wrong! It is as intended... Why change it? What perceived bug is being addressed? No use case is offered for this Look forward to further feedback... thanks... |
|
@geoffmcl ok - what I need is a I have a ~/.tidyrc and the way I build tidy is The regression tests fail if I have a ~/.tidyrc My other use case is for tidy used in a docbook => html make file. If I have a ~/.tidyrc then the tidy'ed result isn't going to match what any other team member gets when they build the documentation. Adding a
There's already a
That I can't tell tidy not to read any init file is, at least for me, a failing. And we touched on this before - you're on windows, so you don't see the problem. CMakeLists.txt has On the other hand, nobody else has commented on this issue so how about we just add a |
|
@ler762 seems two separate things... see if I can deal with each...
This is a BUG and should be fixed! It includes I am not talking about any Try FWIIW I use Would never want to add a
While the above bug is not a valid reason for this new option, it is also true that even As suggested, the tools to run the tests, like your Like using #!/bin/sh
#< tidy-env.sh
TMPVAL=`tidy -help-env`
if [ ! "$?" = "0" ]; then
echo "Running 'tidy -help-env' FAILED"
exit 1
fi
echo "Value in TMPVAL"
echo "$TMPVAL"
echo "process it..."
TMPLINE=0
TMPEXIT=0
echo "$TMPVAL" | while read -r a; do
TMPLINE=`expr $TMPLINE + 1`;
if [ ! -z "$a" ]; then
TMPCNT=`echo "$a" | wc -w`;
if [ "$TMPCNT" = "1" ]; then
if [ -f "$a" ]; then
echo "$TMPLINE: WARNING: File '$a' FOUND!";
TMPEXIT=1;
else
echo "$TMPLINE: File '$a' - NOT FOUND!";
fi
fi
fi
done
exit $TMPEXIT
# eofSo that could be done for the I repeat, given the quite weak
But do think your Maybe even And just so we are clear, would not particularly change the Such a So once the |
|
@geoffmcl I agree there's two separate issues here:
For fixing the design flaw, ''-no-env-config'' sounds too much like "ignore the HTML_TIDY env variable" so I'd go with ''-no-def-config'' allowed anywhere on the command line.
Yup, changing the tests to include this option would be a pain.
I'm ok with ''-no-def-config''
In console/tidy.c, just before add and add the closing bracket right after |
|
drat |
|
@ler762 no I do not think this is a And While I was beginning to think there was a very minor If a As a sysadmin I might not want to allow any So it seems this issue dies for want of a Any last comments... thanks... |
|
The use case is simple: I'd like to have a Note that my definition of reproducible results means that anyone using the same version of tidy as I am, using the same script as I am, gets the same results that I do no matter what's in their/my The regression tests are a good example - it'd be nice if they produced the same results if I have a ~/.tidyrc or not. It seems to me that the easiest way to do that is to have a Same deal with a project I help out with -- the documentation is created using docbook to generate html files and tidy is used to clean up the generated html files. It'd be nice if I could do a Or I could just delete my ./tidyrc |
|
@ler762 if used in a script, why not While easy to achieve, like PR #774, it seems much more difficult to change No feedback in months... Can we close this/these? thanks... |
Because it's so much easier to make sure the script invokes tidy as "tidy -no-config ..." than it is to temporarily rename ~/.tidyrc, call tidy and then undo the earlier rename. If there is an /etc/tidy.conf you can't move or rename it without affecting everybody else that calls tidy during your
processing window. |
|
@ler762 again no further feedback, for months... except Only a Anyway, as yet, do not see sufficient arguments for changing Accordingly, closing this... feel free to re-open... Or better still open a new clean issue... thanks... |
The current configuration file processing behavior is
I don't see a way to prevent tidy from reading /etc/tidy.conf or to tell tidy to be quiet while processing /etc/tidy.conf other than adding a show-info: no as the first line of the file.
I want to be able to tell tidy not to read ~/.tidyrc or /etc/tidy.conf
If nothing else, it'd be nice to be able to run the regression tests without having to make sure ~/.tidyrc doesn't exist
So change the config file processing to
Note that if you have a ~/.tidyrc and you want /etc/tidy.conf read you'll need to have
config /etc/tidy.confin your ~/.tidyrcearlier discussion starts here:
#752 (comment)
The text was updated successfully, but these errors were encountered: