Re: Shell backend: read_and_send_results

[Timur Izhbulatov <TimurIzhbulatov@oilspace.com>]

On Tue, Apr 18, 2006 at 09:38:59PM +0200, Hallvard B Furuseth wrote:
> Dmitriy Kirhlarov writes:
> > We find problem. Return code must be LAST string in backend output
> 
> Yes.  As 'man slapd-shell' says: "The search RESULT should be preceded
> by the entries in LDIF format, each entry followed by a blank line."
> Maybe that needs to be clarified - if so, what should it say?

The slapd-shell man page says:
       The commands - except unbind - should output:
              RESULT
              code: <integer>
              matched: <matched DN>
              info: <text>
       where only RESULT is mandatory.

But the order matters. At least in our case. As Dmitriy said, it works only
when code is in the last line with no trailing newline character.

After some investigation it appeared that the problem is in the way how the
str2result function (servers/slapd/result.c) works. It uses the luitl_atoix
function (libraries/libutil/utils.c) in which:

        i = strtol( s, &next, x );
        if ( next == s || next[ 0 ] != '\0' ) {
                return -1;
        }

If "code: <integer>" is the second line, as the man page says, next[ 0 ]
contains '\n' (the first non-digit character after the integer) and lutil_atoix
fails to convert the code value. That is why it fails if there are any trailing
characters after the value.

Am I missing somethig?

> Timur's test program works for me, even if I insert multiple newlines
> at the end.
> 
> I'm wondering if it could have something to do with how different shells
> treat backslashes and double quotes, so "\n" isn't preserved.

I've also tried the following script:

#!/usr/bin/env python
import sys
write = sys.stdout.write
write("RESULT\n")
write("code: 0")

It's working. But when I insert a newline it's not:

#!/usr/bin/env python
import sys
write = sys.stdout.write
write("RESULT\n")
write("code: 0\n")

That's really weird. Can anybody reproduce our problem?

> Also Timur's program should return an error for unsupported operations,
> and it would fail if it was modified to return a DN which included a
> '%'.  '%s' and '\n' should be in the printf format string, the value in
> the argument to the format string.

Oh, a bug. Thanks!

Cheers,

-- 
Timur Izhbulatov
OILspace, 26 Leninskaya sloboda, bld. 2, 2nd floor, 115280 Moscow, Russia
P:+7 495 105 7245 + ext.205 F:+7 495 105 7246 E:TimurIzhbulatov@oilspace.com
Building Successful Supply Chains - One Solution At A Time.
www.oilspace.com