> 3) I don't think there is any precedence to use environment > variables to change the output in this manner.
What about GCC_COLORS? Didn't know about that one. Thanks! But that only applies to changing GCC behaviour, not all GNU programs. > It would be far easier to, I think, in the long run specially, to > amend the behaviour of -fxxx type of options where they would > produce a warning instead of a hard error. This part of the problem is about giving this option where an old version is installed, and old versions of gcc and bison fail hard. You cannot change old versions retroactively. True, which is why it would be a long term change. > To have different behaviour between compilation runs, I would > recommend creating a config.site file that one uses whith the > specific settings. It's not necessarily site-wide. I may, e.g. build one thing within an editor where I don't want carets, and simultaneously something else on the command-line where I do. It's "job"-wide, and environment variables have exactly the right scope for this. config.site can be site wide, you can also have something like, if $NO_CARET; then FLEXFLAGS=-fno-caret CFLAGS=-fno-diagnostics-caret fi In there to enable/disable things more easily. > In which you can pass the correct flag to the respective > programs. This has the benefit that for the programs that do > have ADA caret output, but do not support this environment > variable, you can still silence it. The user would still need to check each program (regularly after updates) to find out which of them have such options and what they're called in each case. That's an unnecessary burden on the user. The programs themselves know very well what they support in each version, and adding the environment variable check is a one-time job per program (vs. once per user, program, and version). Yes, but the user would have to do that anyway, in the cases where you still get caret output. I would be quite confused if I get caret output despite saying that I don't want it. Not against the idea, just wondering if there might be a better way of doing this that will work with other similar features. You brought up one such example, with GCC_COLORS. Adding a dozen different environment variables every time one wishes to modify the behaviour of various programs seems like a slipery slope. Do we add a NO_WARNINGS? NO_OUTPUT? Maybe just keeping a config.site file that users can install would be much easier, it could be part of the GNU coding standards, as an example, or someone else could maintain it. The benefit of that is that _all_ programs can have supressed output of some sort -- not just programs that support NO_CARET_OUTPU.
