newsyslog(8): Remove -c command line option.

[delphij]

Summary

Following the introduction of the <compress> configuration in
newsyslog.conf, the -c command line is now redundant. Maintaining
this setting in multiple places could lead to confusion for
administrators, therefore, simplify the configuration management
by centralizing compression settings within the newsyslog.conf
file.

[olce]

Hi,

First, two high-level remarks:

1. About the purpose of this change: I've probably not evaluated enough if removing -c is a good idea, so I'm neutral on this topic. Having command-line switches for what can also be specified in a config file generally makes sense to me (with the command-line switch overriding the configuration file). On the other hand, if the program is not to be launched by hand frequently, there is no such necessity. I agree it's best that administrators tweak a common configuration file rather than specifying command-line switches in rc.conf, with the goal to apply the same environment to manual invocations. That said, I'm not sure it's a reason in itself to remove command-line switches.
2. About <compress> : I would really like this directive to be renamed to <compress_override>, since it doesn't affect files that are not already flagged with a compression letter, so the current name is misleading to people that would want to enable compression of all files (which this directive can't do). This would be best done in a separate revision.

The first remark above aside, I'm completely fine with the code changes.

[dvl]

In D43466#990858, @olce wrote:

Hi,

First, two high-level remarks:

1. On the other hand, if the program is not to be launched by hand frequently, there is no such necessity.

edit after reviewing the OP.

I think you're saying why have a command-line switch when we have the in-conf-file option? Tradition. Flexibility. Just specify it when newsyslog is launched. I'm sure there are use-cases where newsylog is not launched from cron, but on-demand (for example). The command-line switch allows the user to accomplish the same thing without modifying their .conf files.

2. About <compress> : I would really like this directive to be renamed to <compress_override>, since it doesn't affect files that are not already flagged with a compression letter, so the current name is misleading to people that would want to enable compression of all files (which this directive can't do). This would be best done in a separate revision.

I like that change.

[olce]

In D43466#990866, @dvl wrote:

I think you're saying why have a command-line switch when we have the in-conf-file option?

I was just trying to guess the reasoning for the removal of this command-line option, by stating one possible inference, since I anticipate that the use of -c is infrequent and it's always possible for the administrator to change the configuration file (well, I also can see situations where these are not equivalent...). Personally, I don't have a need to remove it, and at the same time I'll likely never use it, in that sense I'm neutral.

Tradition. Flexibility. Just specify it when newsyslog is launched. I'm sure there are use-cases where newsylog is not launched from cron, but on-demand (for example). The command-line switch allows the user to accomplish the same thing without modifying their .conf files.

Yes, I generally agree, that's why I wouldn't have proposed to remove -c. Now, I'm wondering why other people think it should be removed.

IIRC, @karels objected to having it because it caused confusion, wondering which one would apply if both -c and <compress> were used. Personally, I don't think it's the case, as so many utilities already have such kind of overlap, with the command-line switch always overriding the configuration file (this can be considered a requirement by POLA).

I think that someone (probably Mike also) says that specifying -c for some manual runs of newsyslog would cause several rotated files not to be compressed with the same method as that in the configuration file, causing a mess. It's not really a problem in my eye, since I've argued that it's easy to read/grep these files uniformly (e.g., with zgrep), and I generally presume the administrator knows what he's doing (unless there's a big risk of foot shooting, but here the administrator can just re-compress existing files after the fact).

It would be better that people really wanting to keep or remove it speak for themselves (probably here, since this is a public forum).

[karels]

In D43466#990869, @olce wrote:

In D43466#990866, @dvl wrote:

I think you're saying why have a command-line switch when we have the in-conf-file option?

I was just trying to guess the reasoning for the removal of this command-line option, by stating one possible inference, since I anticipate that the use of -c is infrequent and it's always possible for the administrator to change the configuration file (well, I also can see situations where these are not equivalent...). Personally, I don't have a need to remove it, and at the same time I'll likely never use it, in that sense I'm neutral.

I objected to having a knob (-c) to override a knob (<compress>) to override a knob (4 different compression indicators). That seems like a bad design to me. That the precedence wasn't specified was an annoyance, but not the primary objection.

Tradition. Flexibility. Just specify it when newsyslog is launched. I'm sure there are use-cases where newsylog is not launched from cron, but on-demand (for example). The command-line switch allows the user to accomplish the same thing without modifying their .conf files.

Yes, I generally agree, that's why I wouldn't have proposed to remove -c. Now, I'm wondering why other people think it should be removed.

See below.

IIRC, @karels objected to having it because it caused confusion, wondering which one would apply if both -c and <compress> were used. Personally, I don't think it's the case, as so many utilities already have such kind of overlap, with the command-line switch always overriding the configuration file (this can be considered a requirement by POLA).

I think that someone (probably Mike also) says that specifying -c for some manual runs of newsyslog would cause several rotated files not to be compressed with the same method as that in the configuration file, causing a mess. It's not really a problem in my eye, since I've argued that it's easy to read/grep these files uniformly (e.g., with zgrep), and I generally presume the administrator knows what he's doing (unless there's a big risk of foot shooting, but here the administrator can just re-compress existing files after the fact).

It would be better that people really wanting to keep or remove it speak for themselves (probably here, since this is a public forum).

Using -c to specify different compression makes a mess because you end up with a mix of different file types/extensions, and the ones created by -c won't get rotated when the cron job runs. They will be numbered separately, so it's hard to figure out the ordering. It doesn't matter that one utility will read from any of them. Also, if one sysadmin adds -c in the cron file, and another tries to figure out what is going on from the config file, or tries to change the config file, they won't get the desired results. I see no good reason to specify a different compression method for individual invocations of newsyslog. Instead, if changing, I would expect the sysadmin to modify the config files and manually rename and/or recompress the existing compressed files.

Unrelated: I think the changes to document <compress> should be in a separate commit. If you do change the name, it might as well be documented under the new name.