RFC 2489 (LDAP Data Interchange Format) says: "An LDIF file consists of a series of records separated by line separators."
This implies that there should not be a blank line at the end of an LDIF file (separator vs. terminator). Believe it or not, this caused a rather heated discussion...
LDAPSEARCH will always include a trailing newline if there is data; is this technically correct behaviour?
Dave Horsfall wrote:
RFC 2489 (LDAP Data Interchange Format) says: "An LDIF file consists of a series of records separated by line separators."
This implies that there should not be a blank line at the end of an LDIF file (separator vs. terminator). Believe it or not, this caused a rather heated discussion...
LDAPSEARCH will always include a trailing newline if there is data; is this technically correct behaviour?
Can you please elaborate what's the issue with this is? I don't know any implementation which has problems with it. BTW: python-ldap's module ldif also generates an empty line at the end of each record, also the last one. And off course when parsing entries this is handled as well.
Ciao, Michael.
Dave Horsfall writes:
RFC 2489 (LDAP Data Interchange Format) says: "An LDIF file consists of a series of records separated by line separators."
This implies that there should not be a blank line at the end of an LDIF file (separator vs. terminator). Believe it or not, this caused a rather heated discussion...
RFC 2849. And the RFC's grammar agrees.
LDAPSEARCH will always include a trailing newline if there is data; is this technically correct behaviour?
No. Nor would a pedantic LDIF parser accept it. I wouldn't suggest changing it at this time though, the behavior is so well established. Maybe in OpenLDAP 2.5, or maybe it's time to revise the LDIF RFC if others are doing the same thing as OpenLDAP. (One advantage of the extra LF at the end is that you can concatenate the output from two ldapsearch -LLL commands.)
On Thu, 21 Feb 2008, Michael Ströder wrote:
LDAPSEARCH will always include a trailing newline if there is data; is this technically correct behaviour?
Can you please elaborate what's the issue with this is? I don't know any implementation which has problems with it. BTW: python-ldap's module ldif also generates an empty line at the end of each record, also the last one. And off course when parsing entries this is handled as well.
I turned the guts of my "ldapdiff" utility into a Perl function to make it available to other scripts, and a colleague complained that when comparing two identical entries a blank line was returned, which I assumed was correct behaviour i.e. no LDIF update commands but you still get the trailing line.
Dave Horsfall wrote:
On Thu, 21 Feb 2008, Michael Ströder wrote:
LDAPSEARCH will always include a trailing newline if there is data; is this technically correct behaviour?
Can you please elaborate what's the issue with this is?
I turned the guts of my "ldapdiff" utility into a Perl function to make it available to other scripts, and a colleague complained that when comparing two identical entries a blank line was returned, which I assumed was correct behaviour i.e. no LDIF update commands but you still get the trailing line.
So I'd consider the diff mechanism needs some work. Not sure what the output of your ldapdiff utility should look like. If it's meant to generate LDIF with change records and there are no changes at all it should return nothing, nada.
This is again a prime example why I most times recommend not to take the loop way over text processing to do database access via LDAP. Rather consider to process diff's directly in syncing processes.
Ciao, Michael.
Dave Horsfall writes:
I turned the guts of my "ldapdiff" utility into a Perl function to make it available to other scripts, and a colleague complained that when comparing two identical entries a blank line was returned, which I assumed was correct behaviour i.e. no LDIF update commands but you still get the trailing line.
You can't make an RFC 2849-compliant "no-op LDIF" in any case. Look at the grammar: It wants one or more entry. ldif-file = ldif-content / ldif-changes ldif-content = version-spec 1*(1*SEP ldif-attrval-record) ldif-changes = version-spec 1*(1*SEP ldif-change-record) Which is silly. That RFC does need some fixes.
Also it wants a "version: 1" line, so I guess an LDIF without "version:" should be said to have some informal pre-RFC LDIF format.
openldap-software@openldap.org
-
Dave Horsfall -
Hallvard B Furuseth -
Michael Ströder