[Date Prev][Date Next]
Re: S/W request: add flag to LDAPSEARCH to identify version (ITS#971)
ident `which ldapsearch`
Though an option could be added to the OpenLDAP tools, this would
not solve your problem as the option name would be vendor specific.
That is, not all vendors will use the same flag to print version
For scripts, I don't recommend relying on detected vendor information.
I recommend specifying tool paths, tool names, and tool arguments
within the scripts (preferable with some localization appropriate
for your environment).
At 04:29 PM 1/22/01 +0000, firstname.lastname@example.org wrote:
>The issue isn't so much as output compatibility as the problem of
>KNOWING which LDAPSEARCH will be used at any given time, and KNOWING
>what output to expect or can be requested. On one machine, I have three
>different LDAPSEARCH modules: vendor installed, Netscape DS V4.12, and
>OpenLDAP-2.0.7. There should be an OpenLDAP-1.2.7 LDAPSEARCH "laying
>around" somewhere as well.
>What I was asking for was a switch that could be used that would tell me
>(the script) what output to expect without any prior knowlege of any
>particular LDAPSEARCH module.
>Having a simple switch and LDAPSEARCH
>one-line response would then let the script know that it needs to
>either, a) abort all pending input and resubmit the search request with
>a different set of switches if it "knows" that it can request the output
>data in a particular format that it can handle, or b) use different code
>to handle the different output format.
>Having an "identity switch" would also allow other vendors to make
>unique changes to their output that could be determined by the one-line
>response from such an "identity switch". Compatibility is nice, but
>doesn't do much good if the script doesn't know anything about the
>LDAPSEARCH module being used.
>On 18 Jan, Kurt D. Zeilenga wrote:
>> At 11:17 PM 1/18/01 +0000, email@example.com wrote:
>>>Full_Name: Jim Dutton
>>>OS: FreeBSD-4.1, Solaris-2.8, NetBSD-1.4.2
>>>Submission from: (NULL) (184.108.40.206)
>>>Well, now that LDAPSEARCH under OpenLDAP-2.0.7 has radically
>>>changed its output from UMich-3.3, OpenLDAP-1.2.x, and
>>>Netscape-3/4 (ie; full LDIF format and extra informational
>>>lines), it would be a good idea to provide some kind of simple
>>>mechanism that can be used to easily identify the version
>>>and source implementation of LDAPSEARCH so scripts can easily
>>>determine whether they are going to have to alter their data
>> Output compatibility with other versions of search
>> tools is provided. You can use this to specify LDIFv1
>> (-L) or U-Mich 3.3/OpenLDAP 1.2 LDIF (-P 2 -LLL).
>> Most vendors provide output in LDIF (v1 and/or U-Mich)
>> format as well, though options to enable it might be