Running a script with cyradm throwing ReadLine errors

[Binarus]

Dear ellie, > I did a bit of reading, and apparently Term::ReadLine is a
stub module that just loads "an implementation", which in your case
wants to be Term::ReadLine::Gnu.  My guess is that, when you uninstall
Term::ReadLine::Gnu, Term::ReadLine no longer successfully compiles
because it's missing an implementation, and consequently the fallback
code I pointed out previously is used instead.  So, from this I'm
concluding that the "correct setup" from above is adequate for the
Cyrus::IMAP::DummyReadline interface, but is not sufficient for a real
ReadLine implementation.  Sounds like we've found our bug!
the more I thought about it, the clearer it got. I do not think any more
that the *real* issue is which stub Term::ReadLine uses.

Different stubs might react differently when fed with undefined file
handles, but this is only a distracting secondary issue. The real
culprit is how the run function is implemented.

Let's consider the original code for that function again:

# trivial; wrapper for _run with correct setup
sub run {
  my $cyradm;
  _run(\$cyradm, [*STDIN, *STDOUT, *STDERR], *__DATA__);
}

How should *__DATA__ have become a handle to the desired file (which
should be executed) in any way? There is absolutely no parameter
parsing, and after having researched what special meaning __DATA__ has,
it became also clear that *__DATA__ isn't mysteriously assigned a
reasonable value before run() is called.

So I made some very trivial changes. The function now reads:

# trivial; wrapper for _run with correct setup
sub run {
  my ($cyradm, $fh);
  my $file = shift;
  defined $file || die "No filename given, aborting.\n";
  open($fh, $file) || die "Could not open file '$file', aborting.\n";
  _run(\$cyradm, [*STDIN, *STDOUT, *STDERR], $fh);
}

Now the whole thing works as expected, regardless of what stub modules
are installed for Term::ReadLine.

We could improve that code further; for example, it lacks a check if
there is the right number of parameters (additional parameters are
currently just ignored). Personally, I wouldn't need detailed checks; I
just want it to execute that script file, avoiding ugly error messages
from Perl itself relating to undefined values and so on.

At a first glance, I couldn't see how the new code could be incompatible
to the existing version. At least, there are no other calls to run() in
that module (only to _run() which I didn't alter). I am quite sure that
you have a bunch regression tests for all your modules, so let's see
what they reveal.

I am looking forward to your comments ...

Thank you very much again!

Regards,

Binarus