Redirected this to openldap-devel list.
ando@sys-net.it wrote:
Quanah Gibson-Mount wrote:
I'm hitting an issue like this in some of the replication tests I'm currently performing. For this purpose, I think we could hack ldapsearch (or add a new prog, or use a script on ldapsearch output) that sorts entries content attribute-wise and, within each attribute, value-wise. Something like "sort" applied entry-wise after unwrapping line folding, optionally case-insensitive would probably suffice.
I have a script somewhere from Matt Backes @ Symas that sorts LDIF files. It was useful for seeing if it made any difference in slapadd (it didn't).
Well, if it were distributable, and written in a widely supported scripting language, it would be quite useful...
What do you consider a "widely supported scripting language"?
During some discussions about the test suite I felt that having a more powerful scripting language would help dealing with some of the problems in a more elegant way.
Ciao, Michael.
Michael Ströder wrote:
What do you consider a "widely supported scripting language"?
During some discussions about the test suite I felt that having a more powerful scripting language would help dealing with some of the problems in a more elegant way.
I know this is going to raise a can of worms. Since we're aiming at all Un*x platforms without very special development tools, I believe plain sh and awk (no gawk or so) is sort of mandatory.
I concur we could make use of much better languages (I'd vote python over perl, but that's personal taste), but I think we cannot have stock tests requiring python right now.
For more specialized things, like developers-only tests python would probably be fine.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------
Pierangelo Masarati writes:
Michael Ströder wrote:
What do you consider a "widely supported scripting language"?
During some discussions about the test suite I felt that having a more powerful scripting language would help dealing with some of the problems in a more elegant way.
I know this is going to raise a can of worms. Since we're aiming at all Un*x platforms without very special development tools, I believe plain sh and awk (no gawk or so) is sort of mandatory.
And sed. All of which are already used in the test scripts.
For stuff these can't handle I doubt Perl has any contenders yet when it comes to what is most widely installed. Well, except Windows scripting languages, whatever they are.
If we want to avoid Perl, we could write some small filters in C. Like this one:
tests/scripts/acfilter.sh requires awk in $PATH to be GNU awk for the ndb tests. On a non-GNU OS it is likely not, even if gawk is installed somewhere. Perl seems better if standard awk is insufficient. With a script which old Perl versions can handle.
Though it's possible to use fall-back solutions on hosts where the preferred scripting language is not available. if <perl is in path>; then <perl script>; elif ...; fi
For scripts that run a lot of programs, redirect the output, the Bourne Shell we already use really is quite powerful. Port a test to Python to see. Likely redirection, error handling and parameter manipulation will grow quite verbose compared to in shell.
I concur we could make use of much better languages (I'd vote python over perl, but that's personal taste), but I think we cannot have stock tests requiring python right now.
For more specialized things, like developers-only tests python would probably be fine.
Yes. Or some shell with more functions to manipulate data than Bourne Shell has.
Pierangelo Masarati wrote:
Michael Ströder wrote:
What do you consider a "widely supported scripting language"?
During some discussions about the test suite I felt that having a more powerful scripting language would help dealing with some of the problems in a more elegant way.
I know this is going to raise a can of worms.
Yes, I know.
Since we're aiming at all Un*x platforms without very special development tools, I believe plain sh and awk (no gawk or so) is sort of mandatory.
So do the Samba people AFAICS. And they have many scripts implemented in Python.
I concur we could make use of much better languages (I'd vote python over perl, but that's personal taste), but I think we cannot have stock tests requiring python right now.
E.g. python-ldap already has a schema-aware dictionary-like Entry class which can handle all sorts of aliasing.
The point why I'm asking is also that I already thought about implementing a test suite for python-ldap which would be the basic tests also useful for OpenLDAP slapd testing.
Ciao, Michael.
Hallvard B Furuseth wrote:
Though it's possible to use fall-back solutions on hosts where the preferred scripting language is not available. if <perl is in path>; then <perl script>; elif ...; fi
Well, implementing fall-backs would undermine the idea to simplify the implementation of test scripts.
Disclaimer: Mainly used to Python myself I'm biased off course.
For scripts that run a lot of programs, redirect the output, the Bourne Shell we already use really is quite powerful. Port a test to Python to see. Likely redirection, error handling and parameter manipulation will grow quite verbose compared to in shell.
Even the main test scripts wouldn't be shell scripts anymore. One would use an unit testing framework for that scripting language and implement test classes for the specific tests. Invoking shell commands can be easily implemented by Python module subprocess (see http://docs.python.org/library/subprocess.html#module-subprocess).
Simple example in the code of the MoinMoin project: http://hg.moinmo.in/moin/1.8/file/f414aece63e0/MoinMoin/_tests/ldap_testbase...
Ciao, Michael.
-
Hallvard B Furuseth -
Michael Ströder -
Pierangelo Masarati