cebtenzzre
commented
1 year ago Tagged paths are described here and at the beginning of the manpage. -k, -K, -m, and -M, apply to tagged paths. Tagging a path is always higher priority than any ranking options specified with -S.
Preferred and tagged do in fact have the same meaning in the source code and documentation. There can be any number of paths before or after the // separator. rmlint doesn't have a complicated algorithm for picking originals, it just has ways of selecting which files have a higher priority for being considered original - mainly tagged paths and ranking (-S, which is pOma by default), but it is also affected by options like --keep-hardlinked.
If you have any specific questions, let me know, but I think the documentation explains it fairly well. I can't really parse all of the guesses you're making, it's a fairly simple interface.
rnsc5jjjjj
I am attacking my big mess, and I am stalled by not understanding how the -S p and P and -k K m M options work with respect to the two syntaxes for the command line paths. I expect that the situation I am struggling with is simple, but I don't see a clear explanation in the documentation. I guess this could be called a shortfall in the documentation. If this can be cleared up, I will propose an update to the documentation. This has to be one of the most thoroughly thought out and careful packages I have ever seen, so somehow I am confident that very likely there is a good an intentional design here.
I think it boils Down to:
How the simple list (rmlint dir1 dir2 dir3) syntax relates to the divided // based (rmlint dir2 dir3 // dir1) syntax. My initial assumption is that the // syntax is a generalization of the simple list syntax, but as I proceeded this leads to contradictions, as I describe below.
How are the -k -K -m -M options applied to the simple list syntax? They are described only with respect to the // syntax. I can guess but I can only guess how they might be applied to the simple list syntax, but the documentation makes no attempt to address both syntaxes, only speaking to the // syntax. Detailed reasoning below.
How are the -S p and -S P options? They are described only with respect to the simple list syntax, and makes no attempt to address the // syntax, which clearly implies by omission that they cannot be used with the // syntax, yet they are needed! To apply their definition to the // syntax is going quite far out on a limb because the definitions cannot be applied to that situation without extrapolating and picking from alternative meanings without any basis. Again, detailed reasoning below.
The sixth paragraph of the man page equates "Preferred" with "Tagged". This seems quite clear, but I am listing it as an assumption to be corrected if appropriate. Further the "Original" is selected from "Preferred" and "Tagged" places if possible. If not possible, it is selected from the "UnPreferred" "UnTagged" "Not-Original" group. I take all of this as given, though not joined in the option documentation.
The -K, -K, -m, and -M options are described relative to the // syntax. If the first named path in the simple syntax is the same as a single element list after the // in the // syntax, then the first element in the simple list syntax is "tagged" and the -k, -K, -m, and -M functionality can be used with this understanding with the simple list syntax. If the first named path in the simple syntax is NOT "Tagged", then -k, -K, -m, and -M cannot be used with the simple syntax, which is a huge loss in functionality, and I think also an unreasonable conclusion. It does not say this anywhere that these options cannot be used with the simple syntax, but I don't see how to escape from this conclusion since their definition is described in terms of the // syntax, and there is no verbiage telling how the two syntaxes relate.
Turning to -S, the p and P options specify keeping the first or last "named path". The fifth paragraph of the man page describes using the "first-named path on the command line" as the original. This is the only other place that I could find that used the terminology "named path," and this wording seems very consistent with the -S p option always "keeping the first named path" (or -S P always "keeping the last named path"). It does not address how this relates to the // syntax where there are two lists separated by //: The first list of Non-Preferred/Non-Tagged paths, the second list of Preferred/Tagged paths. With the simple list syntax the designated "original" path is only a single path, but the "non-original" is a group consisting to the remainder of the list, a group of multiple paths. This isn't much different, though the order of the lists has been reversed. The simple list has the "Original" aka "Preferred" aka "Tagged" first, the // syntax has it the "Preferred" aka "Tagged" last. But both define two distinct lists with the same two roles.
For the simple list syntax, the -S functionality is used to select between candidates within one of the two groups: Either the single "Original" path which could have multiple candidates, or the "non-original" group which could also have multiple candidates. If there are candidates in the "Original" group one of its candidates is selected as the official "original". If not, one of the candidates in the "non-original" group is selected as the official "Original". The -S criteria are applied in order until it is narrowed down to a single candidate (Of course there is the case where there could be multiple candidates after all of the -S criteria are exhausted, but that is another topic and one that I am not concerned with here. In any case the decision can only be arbitrary, e.g. in these situations typically the outcome is "undefined" or "first seen" or "last seen". Don't know what rmlint does, but perhaps in this case it does not matter!)
Given my assumption that the simple list syntax and // syntax are simply different ways to express the two groups of paths, the exact same -S functionality is needed regardless of how the paths are specified.
For the // syntax, a selection to be the "Original" also has to be made, either within the "Preferred/Tagged" group if the duplicate set has a candidate there, otherwise within the "UnPreferred/UnTagged" group. But the -S option does not speak to how the p or P criteria relate when the paths have been specified with the // syntax, it does not have words referring to the // syntax like -k -K -m -M do, just as they did not have words applicable to the simple list syntax. Perhaps "-S p" and "-S P" cannot be used with the // syntax? This seems unreasonable - They are needed. If "-S p (and P)" CAN be used with the // syntax, does the reference to first and last bridge the list on the command line across the //? Or is it applied within the Original/Tagged/Preferred group if it has a candidate, and within the "Non-Original/UnTagged/UnPreferred group if the Original/etc. group if it is the only group with candidates? If it is the "first named path" on the command line and the "last named path" on the command line consistent with paragraph 5 of the man-page where the -S option is introduced, that would bridge the // with the first being on the left side and the last being on the right. With the 'p' criteria this would give preference to selecting a candidate to be the Original from the first of the non-tagged (UnPreferred) set which is counter-intuitive, and the last with 'P' would give preference to the last of the Tagged (Preferred) set which does indeed make sense. But it would make more sense to select within the appropriate group, not the first of last of a list of peer paths within the group. Or perhaps the "-S p" and -S P" cannot be used with the // syntax, but similar to above, it does not say this anywhere, and this would leave a big hole in the functionality, so that must not be true.
Lots of guesses could be made here, but I am hoping that someone can make definitive statements regarding how the two syntaxes relate, how the -S p or P and how the -k K m M options relate to the path specifications for those two syntaxes.
Thank you!