[Date Prev][Date Next]
Re: (ITS#5312) ldapmodify(1) man page claims that "changetype:" not necessary
Howard Chu writes:
> The outcome of the original discussion, which Kurt again reminded me
> of today, was that ldapmodify should quit its guessing games and just
> accept valid LDIF input.
All I see in the -devel discussion is about bugs in the parser. I see
nothing about removing the default "add:"/"replace:" derived from
"changetype:", though perhaps it's in the off-list discussion it refers
> The description of the exceptions in the manpage seemed imply they
> were there to accommodate slurpd users, who needed a mechanism for
> applying failed updates to a target server. Now that all slurpd/replog
> support has been dropped, there really is no more justification for
> these exceptions.
That's not my impression, nor my recollection of the -r option.
The manpage lists some differences from ldif format - replog, and
defaulting changetype, add/replace. But they do not seem related. Not
in the old code either; removing replog code can be done cleanly and
does not interfere with those defaults.
BTW I was wrong about when -r was removed. Seems to have been in the
middle of the 2.0 branch; I only checked the beginning. ldapmodify rev
1.97, May 2 2001 "Clean up some logic, based upon Novell patches". I
see a small patch from Novell shortly before that, ITS#1075, about a bug
in the -r option. The "patches" referred to means more I've missed, I
>> As far as I can tell Logschema doesn't support full LDIF modify though.
>> reqMod is unordered, so one cannot make two modifications to the same
>> attribute. E.g. "delete: foo" followed by "replace: foo".
> I suppose reqMod should be made ordered. My point about logschema is that
> reqMod's syntax doesn't require separators/terminators or as many redundant
> attribute references.
> attr:- foo
> attr:+ bar
> is a far more efficient representation than
> delete: attr
> attr: foo
> add: attr
> attr: bar
Which is why I want the old 'replace:' default back... With a doc
warning that one must use the verbose LDIF format if one wants to not
worry about attribute names like "increment" or "changetype".
> The logschema format is also easily grep-able without resorting to grep
> windowing and other such hassles.
And that was roughly the old ldapmodify format. See manpage umich
ldap-3.3/doc/man/man1/ldapmodify.1. I wonder why we removed it.
There are a few weird LDAP change requests that do not map to that
but that could have been fixed simply by allowing a '-' line as in the
>> Maybe it's time to take this to the ldapext list and hear what others
> This is really getting off topic, unless you're suggesting that we
> spec this for a new version of LDIF.
Not really, more the opposite - if we just relax some restrictions on
the old format ldapmodify accepted before, that's fine.
But otherwise, if we end up inventing a new way to parse ldifs rather
than just accepting more of what the code accepted before, I think it'd
be best to see what others do first. And if so we might as well go
further. I don't suggest that as part of resolving this ITS, certainly.